EMET KOSHER CERTIFICATION

Product Certification Scheme

What this document is. This document is the certification scheme operated by Emet Kosher Certification: the rules under which certification of the kosher status of food products is applied for, evaluated, granted, maintained, extended, reduced, suspended, withdrawn and ended. It is the scheme that ISO/IEC 17065:2012, clause 7.1.1, requires a product certification body to operate, and it is published because a certification body that keeps its own rules private is asking to be taken on trust. The halachic requirements against which products are evaluated are not in this document: they are set out in the Emet Kashrut Standards (EKS-01 to EKS-06, listed in Part VI), each of which is in force only once approved by the Rav HaMachshir. No certificate cites a standard that has not been so approved. This document is controlled by its document code and revision number; it is changed only by a new revision recorded in the revision history at the end of this document, and the revision in force is always the one published on the site.

How to read this scheme

This scheme is one document, but its parts are written for different readers. Nobody needs all of it.

If you buy, stock or eat certified products — read Part I (Scheme foundation), which says what an Emet certificate means and what it does not, and then use the public register and the verification page. Every certificate Emet has ever issued can be checked by its number, and a number Emet has never issued is stated as exactly that. Part V tells you what each designation on the mark means; a mark with no letter is a positive claim that the product is pareve.

If you run a food business and are considering certification — read Part III (The certification process) for what happens between your application and a certificate, and Part IV (Maintaining certification) for what you take on afterwards: surveillance, the duty to tell Emet about changes before they happen, and the ways a certification can end. The certification agreement you will be asked to accept is reproduced in Part VI; nothing is issued until you have accepted it.

If you already hold a certificate — Part IV and Part V are your working documents. Part V, with the mark usage guide in your artwork pack, is part of your licence: no packaging bearing the mark is printed until Emet approves the final artwork in writing.

If you are a rabbinic authority or another certification agency assessing whether to rely on an Emet certificate — read Part I for who holds halachic authority and how rulings are recorded, and Part III for how ingredients are approved (facility-scoped, letter-verified, never global). Emet publishes which agencies' certificates it accepts for ingredients; it makes no claim about who accepts Emet's.

If you are assessing this scheme against ISO/IEC 17065 — read Part II (Requirements on the certification body) with the cross-reference table at the end of this document. The table maps every clause of ISO/IEC 17065:2012 from 4.1 to 8.8 to the part of this scheme that addresses it, and says "not yet addressed" where nothing does. The gaps are stated because a mapped gap can be closed and a hidden one cannot.

If you print packaging — go straight to the prepress technical sheet in the client's artwork pack. Reproduce only from artwork Emet supplies; the designation is part of the mark and is never typeset separately.

Scope

Emet certifies the kosher status of food products, food ingredients and the production lines that make them. Certification is granted per facility: it attests that named products, made at named sites from an approved ingredient list under Emet's supervision, conform to the kashrut requirements determined by Emet's rabbinic authority, the Rav HaMachshir. Certified products may carry the Emet mark with a designation stating what the certificate holds the product to be — pareve, dairy, dairy equipment, meat, or fish. Kosher for Passover is a separate, season-bound certification that expires with the festival it covers. Every certificate is published in a public register, including suspensions and withdrawals, and any certificate can be verified by its number. Emet certifies kosher status only, and does not offer designations it cannot competently staff and supervise.

Conformity statement

This scheme is written to align with ISO/IEC 17065:2012, Conformity assessment — Requirements for bodies certifying products, processes and services, and is structured as a product certification scheme of type 5 within the meaning of ISO/IEC 17067:2013, clause 5.3.7: initial evaluation of the product and its production, followed by surveillance of ongoing production comprising periodic assessment of the production process — plant inspection, announced and unannounced — together with checks of ingredients against the approved list and of marked product against the certificate, with the extent of each surveillance activity set by the risk category of the production. Surveillance under this scheme does not include audit of a management system.

Alignment is a statement about how this scheme is written. It is not a claim of conformity assessed by any accreditation body, peer body or other third party, and Emet holds no accreditation. No such assessment has taken place and none is claimed. Where this document itself records that a requirement of ISO/IEC 17065 is not yet met, that record governs.

The requirements a product is certified against are halachic. ISO/IEC 17065 governs how this body is run — impartially, competently, with decisions separated from evaluations and appeals separated from decisions. It does not and cannot determine what is kosher. Every halachic determination under this scheme — including the standard applied to dairy, the treatment of products for Passover, and the kashering of equipment — belongs to the Rav HaMachshir, and this scheme describes the process by which his rulings are recorded and applied, never the rulings themselves.

Cross-reference to ISO/IEC 17065:2012

This table maps every clause of ISO/IEC 17065:2012 from 4.1 to 8.8 to the section of this scheme that addresses it. Where nothing does, the table says so. An entry marked not yet addressed is an acknowledged gap, held open until it is genuinely closed.

Revision history

Sources verified against the running system (all under /Users/ahmedel-enbabi/Projects/emet/): prisma/schema.prisma (status, decision, case, change-request and revision models), src/lib/conditions.ts and src/server/modules/conditions.ts (the four condition slots and the recorded rabbinic decision), src/lib/agreement-terms.ts (18-section agreement), src/server/modules/certificates/{issuance,revisions,verify,agreement,pack}.ts, src/server/numbering.ts (non-sequential numbers), src/lib/certificate-snapshot.ts (frozen record), src/server/artwork/mark.ts (variant semantics), src/app/(public)/ (scheme, register, verify, fees, complaints, impartiality pages), docs/kashrut-standards.md (EKS status: drafted, pending rabbinic approval), docs/kashrut-operations.md, docs/mark-licence.md, docs/impartiality-risk-register.md (open nonconformities R3/R4 reflected in the table). Standards text: 17065_fresh.txt (clause list 4.1–8.8), 17067.txt lines 372–440 (type 5 at 5.3.7).

Part I — Scheme foundation

1 Purpose and scope of the scheme

1.1 This document is Part I of the certification scheme of Emet Kosher Certification ("Emet", "the scheme"). It states the foundation of the scheme: its purpose and scope, the identity of the scheme owner and of the certification body, the scheme type, the normative and technical basis of certification, the terms the scheme uses, and the products and processes eligible for certification. Later Parts state the certification process, the requirements on the certification body, surveillance, the mark, and sanctions.

1.2 The purpose of the scheme is third-party product certification of the kosher status of food products: an attestation, issued by a body that is neither the producer nor the purchaser, that identified products manufactured at an identified facility conform to the kosher requirements determined under the authority of the Rav HaMachshir (5.20). The scheme exists for the consumer who relies on the mark and cannot verify the claim personally; every rule in it is subordinate to that reliance.

1.3 The scheme is written to align with ISO/IEC 17065:2012 (requirements for bodies certifying products, processes and services) and ISO/IEC 17067:2013 (fundamentals of product certification and guidelines for product certification schemes). Emet holds no accreditation, and no conformity of the scheme or of the certification body with either standard has been assessed by any third party. No claim to the contrary shall appear in any certificate, communication or marketing of the scheme. ISO/IEC 17065, 4.6 requires the body's published information about its scheme, its funding and the rights and duties of its clients to be maintained and available; information that implied an assessment nobody performed would defeat that clause. (The draft of this Part cited 4.1.2.2 c) here. That clause governs the client's arrangements for evaluation, surveillance, complaint investigation and observers, and is not about anybody's claims; the claims obligations on the client are 4.1.2.2 d) and e).)

1.4 Scope of certification. The object of certification is a set of named product lines, each carrying named brands, manufactured at one identified facility. Certification is granted per facility: the same product manufactured at a second facility requires a separate evaluation and a separate certificate. The data model enforces this — a certificate carries exactly one facility, and a certified product line is pinned to that facility by a composite foreign key, so a product certified at one plant cannot be attached to another.

This addresses ISO/IEC 17067, 6.5.1 a) (scope and product types covered) and 6.5.1 i) (unambiguous identification of the certified product): the certificate identifies the holder, the facility, and each certified product line with its classification (5.6) and designations (5.8).

The public register does not always identify all of that, and the difference is deliberate. Three suppressions exist in the system and are exercised at the holder's request: the facility may be withheld entirely (private label and co-packing); a whole certified product line may be marked confidential and omitted from the register; and an individual brand label may be withheld while its product line stays visible. Where a line or a brand is withheld, the certificate itself lists it in full, and the schedule page states in terms that some lines are withheld from the public register — because a reader who counts fewer lines online than on the paper in their hand reads the difference as forgery.

1.5 Sub-schemes. The scheme comprises two sub-schemes, and every certificate belongs to exactly one:

a) STANDARD — year-round certification of ongoing production; b) PASSOVER — seasonal certification for Passover (5.16), whose validity is bound to the festival season it covers and does not carry over to any later year.

The system records the sub-scheme as a non-null attribute of every application and certificate, defaulting to STANDARD. The PASSOVER sub-scheme is defined but not in operation: no Passover condition wording (4.8) has been approved by the Rav HaMachshir, and the system refuses to draft or issue a Passover certificate until one is in force. This is enforced twice over — the snapshot builder refuses to freeze a certificate for which no approved conditions exist for its scheme, and the renderer refuses to print the standard wording ("not certified for Passover") under a title reading CERTIFICATE OF KOSHER SUPERVISION FOR PASSOVER. This is deliberate: a seasonal certificate whose conditions text was never the subject of a rabbinic decision would assert a psak nobody gave.

1.6 Products eligible for certification. Eligible objects are pre-packaged and bulk food products, including food ingredients and processing aids intended for further manufacture, produced at a fixed facility to a defined formulation on defined equipment. Every certified product carries exactly one classification — pareve, dairy or meat (5.6) — and zero or more designations drawn from the scheme's designation register (5.8). The designation register at this issue contains: Cholov Yisroel, Cholov Stam, Pas Yisroel, Bishul Yisroel, Yoshon, Glatt, Beis Yosef, Dairy Equipment, and Kitniyos Free.

Each designation declares which classifications it may sit beside, and this restriction is enforced by the system: a designation that does not apply to a product's classification is refused when the certificate is created, and a reclassification strips any designation that has stopped being true of the new status. Glatt and Beis Yosef are restricted to meat; Dairy Equipment to pareve; the cholov standards to dairy.

1.7 Offered scope at this issue. Eligibility in principle is wider than what the body offers. A designation may be certified only when (a) the scheme has declared it offered, (b) the supervision it requires is staffed, and (c) the Rav HaMachshir has authorised the body in writing to certify it. At this issue the offered scope is intended to be limited to pareve and dairy products of low kashrut risk. Designations requiring dedicated supervision of the production act itself — Cholov Yisroel (supervised milking), Pas Yisroel, Bishul Yisroel, Yoshon, Glatt and Beis Yosef — are defined in this scheme and are not offered.

All three requirements are stated ahead of implementation, and none of them is enforced by the system. The designation register carries an is-active flag, but no code reads it, and it carries no "offered" flag at all: every designation in the register, including the six not offered, can be attached to a certified product today. The register records no staffing and no written authorisation, so requirements (b) and (c) are held on file by the body and nowhere else. Until the register carries an offered flag that the certificate-creation path checks, this restriction is custom, not data, and an assessor should test it against the certificates actually issued rather than against the software.

1.8 Expressly excluded from certification under this scheme:

a) slaughter (shechita) and any meat or poultry processing, until the offered scope is extended under 1.7; b) wine, grape juice and grape derivatives, which are governed by distinct halachic rules requiring dedicated supervision; c) food service, catering, retail premises and any establishment certification — the scheme certifies products, not premises or services; d) certification of persons, of management systems, or of any process detached from an identified product; e) any attestation other than kosher status: the certificate is not a food-safety, hygiene, allergen, "free-from", organic or quality attestation, and is not a halal or any other religious dietary attestation. In particular, an allergen "dairy-free" claim and the kosher classification "dairy" are independent: an allergen-validated dairy-free line can be halachically dairy, and neither claim may be derived from the other.

Exclusions a), b) and c) are policy, not code, and the system contradicts a) today. The meat classification, the MEAT mark variant and the Glatt and Beis Yosef designations are all live and selectable, and the public application form invites meat products by name in its worked example. Nothing refuses a meat application, a wine application or a catering enquiry. Until the intake path enforces the offered scope, the exclusion is operated by the person reading the application, and the application form must be corrected so it stops soliciting what the body will not certify. Exclusion d) is structurally sound: the data model can hold nothing but products of a facility. Exclusion e) is sound: the certificate makes no claim beyond kosher status.

1.9 A certification under this scheme attests conformity as at issue and thereafter only while surveillance is maintained and the register shows the certificate as valid. The certificate instructs verifiers to the public register, and the register — not the sheet — is the statement of current status the body stands behind. ISO/IEC 17065, 7.8 requires the certification body to maintain information on certified products and, as a minimum, to provide information on the validity of a given certification on request; the published register is how this scheme meets that clause and exceeds its minimum.

The system implements this as follows: a verify address is printed on every issued certificate as a QR code and again as text, on the face and on every schedule page; the EXPIRED status is computed at read time from the stored expiry date and is never itself stored, so no scheduled job can leave the register lying; and a suspended, withdrawn or terminated certificate is published as such, with its effective date, the body's written reason, and the history of status changes.

Two limits on that last sentence. The scheme's internal reason categories are recorded but are not themselves published; what a reader sees is the status, the date and the body's written reason. The single exception is a withdrawal recorded as issued-in-error, which the register publishes in its own wording — that the number never represented a valid certification and that a document bearing it should be reported — because "revoked" would be untrue in one direction and unfair in the other.

2 The scheme owner and the certification body

2.1 The scheme owner is Emet Kosher Certification. The scheme owner is responsible for the objectives, content and integrity of the scheme (ISO/IEC 17067, 6.3.4), maintains it and its documentation (6.3.5, 6.3.7), and shall be constituted as a legal entity answerable for those responsibilities (6.3.3). The scheme owner develops the scheme using competence in both the technical field — kashrut — and in conformity assessment (6.3.8): every kashrut-substantive element of the scheme requires the sign-off of the Rav HaMachshir before it takes effect, and every process element is drafted against ISO/IEC 17065 and ISO/IEC 17067 with the clause traced. Whether the legal entity has been constituted is a matter of record outside this system.

2.2 The certification body operating the scheme is Emet Kosher Certification itself. At this issue Emet is the sole certification body; the scheme does not license, and has no procedure for licensing, any other certification body, and the data model has no concept of one. Should the scheme owner later admit other bodies, the requirements of ISO/IEC 17067, 6.5.1 e), f) and p) (requirements on certification bodies, their qualification, and access criteria) will be added to this scheme before any such admission.

2.3 The certification body operates independently. It is not publicly associated with, and does not trade on the name of, any other organisation, and it claims no recognition, acceptance or reciprocity by any other kosher certification agency. The system records which other agencies' ingredient certifications Emet accepts, as an internal reference list used in ingredient approval; that list is not published, and no public page of this scheme names another certifying body. The scheme may publish which agencies Emet accepts; it shall never publish or imply which agencies accept Emet.

2.4 Rabbinic authority and certification decisions. All halachic authority under the scheme vests in the Rav HaMachshir (5.20). The certification body's staff administer the process; they do not rule.

The system enforces two things and no more. First, no certificate can issue without a signatory carrying a name: the name, title and authority are frozen into the certificate snapshot and printed on the sheet, and issuance is refused if the snapshot carries no signatory name. The Hebrew name is optional and is printed only when it has been recorded. Second, every change to the conditions text a certificate prints must record the signatory whose decision it is, the date the decision was given, and the channel by which it reached the office (in person, by telephone, by email, in writing); the record is refused if the date is in the future or more than ninety days past, and where the operator is not that rav's own account, the record and the audit trail both say the decision was recorded on their behalf.

What the system does not enforce is that the named signatory is a real appointed rav. The seeded signatory is an explicit placeholder — see 5.20 — and nothing refuses a certificate issued against it.

2.5 Separation of roles. Review shall be carried out by persons who took no part in the evaluation (ISO/IEC 17065, 7.5.1), and the certification decision shall be made by a person or group who took no part in the evaluation (7.6.2). ISO/IEC 17065 expressly permits the review and the decision to be completed by the same person or group; it does not permit either to be done by the evaluator. Separation of the commercial function from the decision is a requirement of 4.2 (management of impartiality), not of 7.5 or 7.6, and this scheme adds it: nobody who sets or collects fees takes part in a certification decision.

This requirement is stated ahead of implementation and is recorded in the body's internal impartiality risk register as an open nonconformity against 7.5, 7.6 and 7.13.5. The software today permits the person who drafted a certificate revision to issue it — issuance requires an administrator and checks nothing about who drafted. The decisions table intended to record the rabbinic decision separately from the certificate it produced has no write path at all: no code in the system creates a row in it, so the certification decision exists nowhere as data.

That gap propagates. The complaints and appeals module contains a non-involvement check that blocks anyone who made a certification decision on a certificate from deciding a case about it — but the check reads the decisions table, so it can never fire. The guard that does operate is the stricter appeal test: for an appeal, anyone who authored a revision on that certificate is blocked from deciding it, and revision authorship is recorded. So non-involvement is enforced for appeals against people who drafted, and is not enforced at all for complaints or for decision-makers.

An assessor should treat any file in which one person performed evaluation and decision as a nonconformity against this clause, and should not rely on the complaints module's decision-maker guard.

2.6 Impartiality. The certification body shall identify, analyse and respond to threats to impartiality on an ongoing basis (ISO/IEC 17065, 4.2), including the specific threats of fee dependence on individual clients, reliance on a single rabbinic authority, common ownership with another certification business, and external pressure. The body publishes an impartiality policy and maintains an internal impartiality risk register that records each of those threats with its controls and its residual risk.

Not yet implemented: no impartiality committee or comparable mechanism (ISO/IEC 17065, 5.2) is evidenced in the system, and no declarations of interest are recorded as data — there is no conflict-of-interest model of any kind, although the published impartiality policy tells the public that conflicts are declared before anyone touches a file.

Fees are addressed by a published fees policy — a fee buys evaluation and never a certificate; fees are agreed only after the rabbinic decision; nobody who sets or collects fees decides certification; unannounced visits are covered by the annual fee rather than billed as extras; and complaints, appeals, suspension and withdrawal are never charged for. No financial records of any kind exist in the system — there is no fee, quotation, invoice or payment model — so the policy's operation cannot be demonstrated from records held here.

2.7 The scheme owner shall manage the risks and liabilities arising from the scheme and hold arrangements (insurance or reserves) to cover them (ISO/IEC 17067, 6.3.10–6.3.12; ISO/IEC 17065, 4.3). This is a requirement on the body, and no such arrangement is recorded anywhere in the system — while clause 2.7 of the certification agreement already promises every holder that the body maintains it. Until the arrangement exists and is recorded, that clause is a promise with nothing behind it, and closing this gap ranks ahead of anything cosmetic in the scheme.

3 Scheme type

3.1 The scheme is a type 5 scheme within the meaning of ISO/IEC 17067, 5.3.7. It comprises all five common certification functions of ISO/IEC 17067, Table 1 — selection, determination, review, decision, and attestation by certificate and by licence to use a mark — together with surveillance of ongoing production.

3.2 Reasoning. The classification follows from three facts of kosher certification, mapped to the text of ISO/IEC 17067:

a) The attestation must cover ongoing production, not only the items examined. Under 5.3.1, types 1a and 1b carry no surveillance because the attestation "relates only to the product items which have been subjected to the determination activities"; a kosher mark on next month's production run would therefore be an unattested claim under either type. Types 1a and 1b are excluded.

b) The mark is affixed to the product itself. Table 1 grants the licence to use a mark of conformity on the basis of surveillance, and ISO/IEC 17065, 7.9.3 provides that where continuing use of a certification mark is authorised for placement on a certified product, its packaging or accompanying information, surveillance "shall be established and shall include periodic surveillance of marked products to ensure ongoing validity of the demonstration of fulfilment of product requirements". Surveillance is therefore mandatory in this scheme, and 7.9.3 specifies what it must include. See 3.4 a): the body does not yet do it.

c) Kosher conformity is dominated by process and inputs — ingredient provenance, equipment status, segregation, supervision — not by a laboratory-detectable property of the finished item. The surveillance that matters most is therefore periodic assessment of the production process, which 5.3.7 provides, while 5.3.7 also permits "the extent to which the four surveillance activities are conducted" to be varied "for a given situation, as defined in the scheme". This scheme uses that permission to scale supervision intensity with the risk category of the facility — cold pareve, heated, dairy, shared line, meat. This is a requirement stated ahead of implementation. The five risk categories exist in the data model as an enum on the application record, and no code writes or reads them; no certificate, facility or visit carries a risk category, and nothing in the system varies anything by risk. Until the risk category is set at triage and drives the visit plan, risk-based intensity is operated on paper.

3.3 Against type 6. Type 6 (5.3.8) is "mainly applicable to certification of services and processes" and was considered because kosher status is process-borne. It is rejected because the object of attestation and the carrier of the mark is the traded product, not an intangible service; because type 6 surveillance is built around management-system audit, which many food plants within scope cannot meaningfully offer and which 5.3.7 leaves optional; and because everything type 6 would examine — procedures, resources, controls — is available within type 5 as assessment of the production process. Nothing is gained and the consumer-facing product claim is misdescribed.

3.4 Configuration of surveillance at this issue. Of the four surveillance activities 5.3.7 permits, the scheme currently operates one: periodic assessment of the production process, by supervision visits including unannounced visits, with graded findings (minor, major, critical), corrective actions and due dates required on every finding, and a written closure note required to close one. Open corrective actions at the facility block the issue of a renewal, and this is enforced inside the issuance transaction rather than merely stated on a screen. The system records all of this. Three limitations are stated:

a) Sampling of product from the point of production or from the market, and its determination, is not implemented. No sampling, testing or in-trade label check exists in the system. This is not only an unmet requirement of the scheme's own EKS-04 (4.4) — because the mark is authorised for placement on ongoing production, it is an open nonconformity against ISO/IEC 17065, 7.9.3, which requires surveillance to include periodic surveillance of marked products. Until it operates, the scheme's type 5 configuration is exercised through process assessment only, and the body cannot demonstrate the ongoing validity of what is on the shelf. This is the most serious gap in Part I.

b) No surveillance schedule is computed. Visits are recorded after the fact. Nothing in the system plans a visit, derives a next-due date, or flags a facility as overdue for one. The nightly sweep does flag corrective actions past their due date, supplier letters within sixty days of expiry, and certificates within sixty days of expiry — but nothing about visits. The visit frequency by risk category required by EKS-04 is therefore operated manually, and by a risk category the system does not hold (3.2 c). An assessor should test visit frequency from the visit records, not from any planner.

c) Supervisors are not a register. A visit records its supervisor as a free-text name (5.19), so the system cannot demonstrate that a given visit was made by a qualified mashgiach.

Management-system audit is not part of this scheme's surveillance and no initial management-system audit is required.

3.5 Batch certification reserved. A single supervised production run (for example, one Passover production window) is in principle certifiable as a defined batch under ISO/IEC 17067, 5.3.3 (type 1b). The scheme reserves this modality and does not currently offer it: the system carries no lot, quantity or seal records, and until it does, a batch attestation could not be evidenced. Any future offer of batch certification will be added to this scheme in writing first.

4 Normative and technical basis

4.1 Two bodies of requirements meet in this scheme and their jurisdictions do not overlap. Halacha — Jewish law as determined for this scheme by the Rav HaMachshir — governs what is kosher: every certification requirement that touches what may be eaten derives from it and from nothing else. ISO/IEC 17065 and ISO/IEC 17067 govern how the body certifies: process, impartiality, records, surveillance, sanctions. Codex Alimentarius CXC 1-1969, General Principles of Food Hygiene (revision 2022), is the scheme's baseline expectation of the production environment in which kosher conformity is evaluated. No document in this scheme creates halacha; the scheme documents record rulings and define process.

4.2 The halachic authority. The kosher requirements applied under this scheme are the rulings of the Rav HaMachshir. Where recognised halachic practice varies — the acceptability of cholov stam, the standard applied for bishul yisroel, the treatment of kitniyos, the application of bittul, the method of kashering required for particular equipment — the scheme does not select among positions in this document. It states the process: the question is put to the Rav HaMachshir, the ruling is recorded with its date and the channel by which it was given, and the certificate states the position it was certified under where the reader needs it to eat correctly (see 4.8).

Public explanatory pages describing halachic positions shall be published only after the Rav HaMachshir has signed them off, because the market reads them as the body's psak. This requirement is not currently met. The body's published classifications reference is live and states positions on cholov stam, on the Ashkenazi and Sephardi standards for bishul yisroel, and on kitniyos. No sign-off of that page is recorded anywhere in the system, and the system's only signatory is a placeholder (5.20). Either the page is withdrawn until it is signed off, or the sign-off is obtained and recorded; leaving it published unsigned is the body giving a psak nobody gave.

4.3 Codex CXC 1-1969 as the hygiene baseline. A facility within scope is expected to operate the good hygiene practices of CXC 1-1969 — in particular section 5 (general principles, including the science-based preventive approach, and at 5.1 management commitment and food safety culture), section 11 (establishment maintenance, cleaning and disinfection, and pest control), section 12 (personal hygiene) and section 13 (control of operation). The scheme uses this baseline in three ways:

a) as an eligibility presumption: certification is evaluated in a plant presumed to produce safe and suitable food; the scheme is not a substitute for the operator's legal food-safety duties and does not audit them;

b) as an evaluative signal: the control disciplines CXC 1-1969 requires — segregation, changeover control, cleaning verification, and monitoring, corrective action, verification and documentation of control measures (section 5, principle (vi)) — are the same disciplines kosher segregation depends on, and a facility that cannot demonstrate them cannot maintain kosher status on a shared line;

c) as a floor, never a ceiling: where halacha requires more than hygiene, halacha governs the kosher determination. The canonical case is kashering (5.14): a caustic clean-in-place cycle satisfying CXC 1-1969 section 11 is cleaning, not kashering, and equipment so cleaned has not changed kosher status. Conversely, nothing in a kosher requirement reduces any hygiene obligation.

Conformity with CXC 1-1969 is not what the certificate attests (see 1.8 e)).

4.4 Scheme normative documents. The kashrut requirements of the scheme are carried in six Emet Kashrut Standards: EKS-01 General requirements for kosher certification; EKS-02 Classification and designation; EKS-03 Ingredient approval; EKS-04 Supervision and surveillance; EKS-05 Passover; EKS-06 Use of the mark. EKS-06 is written and is issued to every certificate holder as the mark usage guide, generated per certificate and delivered in the client artwork pack alongside the certificate and the exact mark lockups that certificate authorises. EKS-01 to EKS-05 exist at this issue as a one-paragraph scope statement each and are not in force: nothing in them binds anyone until the Rav HaMachshir has signed each off, and no certificate may cite a document that has not been.

4.5 Stated gap. ISO/IEC 17065, 7.1.2 requires the requirements against which products are evaluated to be those contained in specified standards and other normative documents. 7.7.1 d) requires the certification documentation to convey the scope of certification, which 3.10 defines to include "the standard(s) and other normative document(s), including their date of publication, to which it is judged that the product(s) … comply". 7.8 b) separately requires the body's directory of certified products to contain those same documents.

Certificates issued by the system today cite no normative document, and neither does the public register, because none is in force. This is a known nonconformity of the scheme's current operation against its own basis, on three clauses rather than one. The closure path is fixed and ordered: the Rav HaMachshir approves EKS-01 to EKS-05; the body staffs what each requires; the documents are published; the certificate template and the register entry cite them, with their dates of publication. Certificates are not held back in the interim — the requirements actually applied are the recorded rulings of the Rav HaMachshir — but an assessor should treat the absent citation as open until the EKS documents issue.

4.6 Order of precedence. In any conflict: (1) a recorded ruling of the Rav HaMachshir; (2) the EKS documents once in force; (3) this scheme document; (4) guidance and explanatory material. No conflict with ISO/IEC 17065 can be resolved by this order in the body's favour: where this scheme is silent or laxer than ISO/IEC 17065 on a process matter, ISO/IEC 17065 governs. Its Introduction states that it does not set requirements for schemes, "however scheme requirements should not contradict or exclude any of the requirements of this International Standard".

4.7 Document control. Scheme documents are maintained, versioned and controlled by the scheme owner (ISO/IEC 17067, 6.7). Every document the body produces carries a control line naming the form and the revision of that form, distinct from the certificate number, which names the record.

The certification agreement is version-controlled in the system and the control is real: sending an agreement freezes that version's clauses onto the certificate record; acceptance records who accepted, when, from which address, and which version, and stamps the version that was sent rather than whatever the constant has since become; and issuance is refused unless the version accepted is the current one, with the message naming both versions. A declined agreement records the client's reason rather than being treated as silence. The agreement at this issue is 18 sections and 81 clauses, numbered within their section so that a notice can cite one.

4.8 Conditions text. Every certificate carries four mandatory condition statements, composed by the system into two printed lines that appear on the certificate face and again on every schedule page. The four are: whether the certification travels with the pack or only with the mark printed on it; the product's Passover fitness, stated either way; the cholov standard dairy under the certificate is held to; and what the sheet alone does and does not prove.

The system enforces that no slot is empty and that the author does not choose the line break, because silence is read as a claim — an unstated Passover status looks like fitness for Passover, and dairy with no cholov standard stated will be taken by the stricter consumer as one they may drink. The words are frozen into the certificate snapshot at drafting and the PDF renders from the snapshot, so two copies of one certificate can never say different things and a certificate issued under older wording re-renders in its own wording.

The wording of these statements is itself a halachic instrument: it may be changed only through a recorded decision of a named signatory (2.4), one standing set per sub-scheme, with a certificate-specific set able to override it where a blanket line would be wrong for that plant — a wholly cholov-yisroel facility must not carry a blanket cholov-stam line. Nothing is edited in place; a revision rejects the standing proposal and inserts the next version, and nobody may record a decision on wording they have not opened on a rendered specimen.

The wording currently in force is seeded — carried over verbatim from the constant it replaced, marked in the system as originating from seed data, nobody's decision. Every screen that displays it says that no rav's decision is recorded against it, and it will keep saying so until a decision is recorded — which the Rav HaMachshir may do either by approving new wording or by adopting the existing wording unchanged, with the date it was given and the channel by which it reached the office. Both routes exist in the system; both leave the same record.

5 Terms and definitions

For the purposes of this scheme the following terms and definitions apply. Where a term denotes a halachic category, the definition here is descriptive; the operative meaning in any certification decision is the meaning given to it by the Rav HaMachshir (4.2).

5.1 kosher — fit for consumption under halacha, as determined for this scheme by the Rav HaMachshir. Kosher status is a property of a specific product from a specific facility under specific conditions; it is not a property of a recipe alone, and it is not a hygiene, safety or quality grade.

5.2 kashrut — the body of halachic law governing food, and by extension the discipline of supervising conformity with it.

5.3 hechsher — the attestation of kosher status by a rabbinic certifying body, typically manifested as a mark on the product. Under this scheme the hechsher is the Emet mark together with the certificate and register entry behind it.

5.4 certificate — the document issued under this scheme attesting kosher status of the listed products of one holder at one facility, valid only as shown in the public register.

5.5 mark — the registered Emet symbol licensed to a certificate holder for application to certified products. The system generates the mark per certified product line in exactly one variant, and the variant is a required argument with no default, because a plain unsuffixed mark is not a neutral logo but a positive claim that the product is pareve. The variants and their meanings are: plain (pareve), PAREVE (pareve, stated explicitly), D (dairy), MEAT (meat), DE (dairy equipment), P (kosher for Passover — never an abbreviation of pareve), FISH (contains fish). A client's artwork pack contains the lockups their certificate authorises and nothing else.

5.6 classification — the base kosher status of a certified product line: exactly one of pareve, dairy or meat. Every other status a product can carry is a designation (5.8), never a fourth classification.

5.7 pareve — containing neither dairy nor meat, and consumable with either. Pareve status transfers through heat and shared equipment: a pareve formulation run hot on dairy equipment is no longer pareve. An unmarked Emet symbol declares pareve (5.5).

5.8 designation — a kashrut status a certified product carries in addition to its classification, drawn from the scheme's designation register, each designation restricted to the classifications it may apply to. That restriction is enforced by the system (1.6). Which designations are offered is not (1.7).

5.9 dairy (chalavi) — containing dairy ingredients; never combined with meat. Carries the D variant of the mark.

5.10 meat (basari) — containing meat, including poultry; never combined with dairy. The mark spells MEAT in full because a bare M is ambiguous. Not within the offered scope at this issue (1.7), a restriction the system does not enforce (1.8).

5.11 dairy equipment (DE) — the designation of a pareve-formulated product produced on equipment that also runs dairy. A DE product is not pareve, and DE is a kosher status, not an allergen claim: a DE product can be allergen dairy-free (1.8 e)). Applies to pareve-classified products only.

5.12 cholov yisroel — dairy supervised by an observant Jew from the milking onward. cholov stam — ordinary commercial milk, accepted by many mainstream authorities on the basis that governmental dairy regulation provides the needed assurance; not accepted by stricter communities. Which standard a given certificate's dairy is held to is a ruling of the Rav HaMachshir and is stated on the face of every certificate (4.8); Emet does not offer the Cholov Yisroel designation (1.7).

5.13 pas yisroel — baked goods in whose baking a Jew participates, typically by lighting or activating the oven; a per-production-run designation, not a property of the recipe. bishul yisroel — for foods not edible raw and fit for a formal table, cooking in which a Jew participates; the degree of participation required differs between recognised traditions, and the standard applied under this scheme is the ruling of the Rav HaMachshir. Neither designation is offered (1.7).

5.14 kashering — the halachically prescribed process by which equipment is restored to a kosher status or transitioned between statuses. The required method depends on the equipment and its use and is determined case by case by the Rav HaMachshir. Cleaning is not kashering: a validated clean-in-place cycle changes hygiene status, not kosher status (4.3 c)).

5.15 bittul — the halachic principle under which a forbidden or status-bearing component may, in defined circumstances, be nullified in a permitted majority. The scheme states the process rule only: no client, supervisor or staff member may rely on bittul in formulating, producing or approving anything under this scheme; deliberate nullification is not a route to conformity; whether bittul applies to any incident (for example, an inadvertent trace admixture) is a ruling reserved exclusively to the Rav HaMachshir, made after the fact and recorded.

5.16 Passover (Pesach) — the festival during which chametz is forbidden. Under this scheme, a Passover certification is a separate seasonal sub-scheme (1.5 b)), and its validity window is computed from the Hebrew calendar rather than typed: a Passover certificate runs to the last day of the festival it covers and not one day further. Its mark variant is P. The scheme requires P artwork to be season-bound, and this is not implemented: the artwork generator carries no expiry and no season. The point is currently moot — no Passover conditions exist, so no Passover certificate and therefore no P lockup can be produced at all — but the binding must exist in the generator before the first Passover certificate issues, because P artwork reused the following year covers a production nobody supervised.

5.17 chametz — leavened products of the five grains, forbidden on Passover. A product containing or contacting chametz cannot be certified under the PASSOVER sub-scheme regardless of its year-round status.

5.18 kitniyos — legumes, rice, corn and their derivatives, avoided on Passover by Ashkenazi practice and permitted to most Sephardi practice. Because glucose, starch, lecithin and oils are commonly corn- or soy-derived, kitniyos policy pulls whole ingredient classes into a Passover programme; the policy applied is the ruling of the Rav HaMachshir. The designation register carries Kitniyos Free for products certified as containing none.

5.19 mashgiach — the supervisor who physically inspects and supervises production on the body's behalf (also: Rabbinic Field Representative). The scheme requires a mashgiach to meet the personal qualifications set by the Rav HaMachshir. Not implemented: the system records a supervision visit's supervisor as a free-text name only; no register of mashgichim, their qualifications or their authorisations exists as data, and nothing links a visit to a qualified person. The identity and movements of mashgichim are never published, as a safety matter and not only a confidentiality one.

5.20 Rav HaMachshir — the certifying rabbi: the named halachic authority in whom every ruling under this scheme vests, who alone makes the certification decision, and whose name, title and authority appear on every certificate as its signatory, with the Hebrew name where one has been recorded. No certificate can issue without a named signatory, and the system ships with an explicit placeholder signatory — named "to be appointed", with a note saying it must be replaced before any certificate is issued — so that the dependency on the appointment is visible rather than silent.

The scheme requires that no certificate may issue against that placeholder, and the system does not enforce it. The issuance gate tests only that the frozen snapshot carries a signatory name, and the placeholder has one. Until the gate refuses the placeholder by identity rather than by emptiness, a certificate can issue over a rav who does not exist, which is the single failure this scheme is least able to survive. Whether an appointment has since been made is a matter of record outside this document.

5.21 facility — the single production site to which a certificate, its approved-ingredient list and its supervision attach (1.4).

5.22 approved-ingredient list (Schedule A) — the facility-scoped register of ingredients evaluated for use in certified products, each identified by name, producer, producing plant and item code — the producing plant and not the distributor, because two plants of one producer are two different kashrut facts — and each carrying exactly one status: pending, approved, restricted to source, rejected, or innocuous (acceptable from any source, which is still a recorded decision with an owner). Approval is facility-scoped, never global, and this is enforced in the database: the same ingredient may be approved at one plant and unapproved at another, and an approval made at one facility physically cannot be linked to a product certified at another.

5.23 letter of certification (LOC) — a supplier's kosher certificate for an ingredient, recorded against the approval for the exact producing plant and item code, with its claimed status (pareve, dairy, dairy equipment, meat, or fish) as a closed value rather than free text, its expiry date, and the person who verified it; superseded, never overwritten, so that "was this ingredient covered by a valid letter during the March run" can still be answered. A letter whose claim is dairy cannot support a pareve use. This cross-check is a requirement of EKS-03 and is not computed by the system, which today displays the claim beside the approval without testing it against the classification of any product the ingredient goes into. The nightly sweep does flag letters within sixty days of expiry.

5.24 fish — a status claim carried by supplier letters and defined for the mark (5.5). Gap: the product classification model records only pareve, dairy and meat, so no certificate issued today can generate the FISH mark variant. The variant is defined and reserved, and the claim is recordable on an ingredient letter, but the status cannot travel from the ingredient to the certified product.

Part II — Requirements on the certification body

6 Legal and contractual matters, liability, financing and access

6.1 Legal status

6.1.1 Emet is a legal entity and is responsible in law for all of its certification activities (ISO/IEC 17065, 4.1.1). The registered name and address of the body appear on the face of every certificate it issues — they are held in one place and printed into the footer of the certificate, the schedule, the agreement, the usage guide and the client pack, so that no two Emet documents can locate the body differently — and in the certification agreement.

6.1.2 Emet operates under its own name only. It makes no claim of standing derived from any other body, agency or undertaking, and no claim that its certification is accepted or recognised by any third party; it never publishes, implies or permits a claim about which agencies accept Emet.

Which other kashrut agencies' certificates Emet accepts for ingredient approval is recorded in the system as a decision attached to each agency, and an ingredient may not be approved on the strength of an agency not so marked (clause 9.3.2). That list is not published. It exists only on the internal Schedule A screens. Publishing it is the business of EKS-03, which is not in force (clause 8.5.3); until then the acceptance list is an internal control, and this scheme does not claim it as public information.

6.1.3 This scheme is written to align with ISO/IEC 17065:2012 and ISO/IEC 17067:2013. No assessment of that alignment by any external party has taken place, and nothing in this scheme, on a certificate, or on any Emet publication shall state or imply otherwise. The published site says the same thing in its own words: no accreditation programme exists for kosher certification anywhere, and any body implying it holds one is saying something that cannot be true.

6.2 The certification agreement

6.2.1 Certification is provided only under a legally enforceable written agreement between Emet and the client (ISO/IEC 17065, 4.1.2.1). The agreement in force is the Emet Certification Agreement, version 2026-08.2, of eighteen sections and eighty-one clauses. It is maintained as a single controlled text in the certification system; it names no external standard, because the requirements it binds the holder to are those of this scheme.

6.2.2 The agreement gives effect to every element of ISO/IEC 17065, 4.1.2.2 a)–k), as follows: continuous fulfilment of the certification requirements on every production day (agreement §4); access for evaluation and surveillance, expressly including unannounced visits during production hours, observers, sampling, complaint investigation, and the securing of identical access rights at any co-packer (§5); prior notification of any change of ingredient, supplier, formulation, processing aid, shared equipment, production method, place of manufacture or mark-bearing packaging, with approval never granted retrospectively (§6); a kosher complaints record kept by the holder (§7); surveillance as the standing basis of the mark licence (§8); the certificate remaining Emet's property, reproduced only in full, and valid only while the public register says so (§9); the mark held under a revocable, non-transferable licence, used only on scheduled products, only from artwork Emet supplies, with written approval before printing and the usage guide incorporated by reference (§10); discipline of claims and references to certification (§11); confidentiality, with the public register named as the exception the holder consents to by accepting (§12); the obligations on suspension, reduction, withdrawal and termination, including destruction of unused mark-bearing packaging within thirty days and cooperation with any recall (§13); records on both sides (§14); implementation of changed requirements (§15); complaints and appeals, including the non-involvement rule and a prohibition on retaliation (§16); and the allocation of liability, under which responsibility for conforming product remains with the holder (§17).

6.2.3 The system enforces the agreement mechanically. Sending an agreement freezes its clause text onto the certificate record, so that a past acceptance can never be re-read under later wording. Acceptance records the accepting individual, the time, the originating address and the version accepted. Decline is a recorded first-class answer with a written reason, and it alerts the office by mail rather than leaving the file to go quiet. Issuance of a certificate is refused unless the agreement status is ACCEPTED and the accepted version equals the version currently in force. When the agreement text changes (agreement §18), existing holders must re-accept before any further issue on their file.

6.3 Control of licences, certificates and marks

6.3.1 Emet exercises the controls of ISO/IEC 17065, 4.1.3.1 over ownership, use and display of its certificates and mark. The Emet mark is a sixteen-scallop seal, the scallop count being fixed by the mark specification and not a design variable. It is issued only as complete lockups, in which the designation is part of the artwork and cannot be typeset, substituted or moved by the holder. The lockups are: the plain seal, which carries no suffix and is itself the positive claim that the product is pareve; PAREVE, the same claim stated in words; D for dairy; DE for pareve made on dairy equipment; MEAT, spelled out because a bare M is ambiguous; FISH, likewise spelled out; and P, which means kosher for Passover and never pareve.

The set of lockups a holder may use is derived by the system from the certificate itself — from each certified product's classification, its designations and the scheme — and never chosen by hand. The artwork pack delivered through the client portal contains only those lockups, in print and digital cuts, together with the certificate, the prepress specification, the usage guide and a manifest naming which products each lockup is authorised for. The portal refuses the pack for any certificate that is not active.

6.3.2 The certificate states, and the agreement requires, that label artwork bearing the mark be approved in writing before printing (agreement §10.4).

The system carries the deciding half of this control and not the submitting half. An artwork decision screen exists; it recomputes the lockups the certificate authorises and refuses to approve any artwork bearing a lockup outside that set, refuses to approve artwork with no file attached, refuses to approve against a certificate that is not active, and shows a standing warning where the mark and the product's classification disagree. No path exists by which artwork can enter that screen: nothing in the system creates an artwork record or stores an artwork file, so the decision queue is permanently empty and no artwork record can reach an approved state in software. Until the submission path is implemented, artwork is sent to the address named in the client pack, written pre-print approval is given and retained outside the system, and the absence of the in-system record is a known gap, not a waiver of the requirement.

6.3.3 Incorrect references to certification and misleading use of the certificate or mark (ISO/IEC 17065, 4.1.3.2) are addressed by a graded ladder: corrective action demanded of the holder; suspension or reduction; withdrawal with publication on the register; and, for continued use of the mark after withdrawal, enforcement as trademark infringement. The agreement provides in advance that Emet may publish a corrective notice identifying the product and its status, and that such publication is not a breach of confidentiality (§10.6). Discovery of a certificate presented outside its register status is aided by the verification services (clause 8.4 of this scheme), which distinguish a current document from a superseded or altered one.

6.4 Liability and financing

6.4.1 Emet shall maintain adequate arrangements — insurance or reserves — to cover liabilities arising from its operations, sized against the exposure particular to food certification, including recall of mislabelled product (ISO/IEC 17065, 4.3.1), and shall have the financial stability and resources its operations require (4.3.2). The agreement states the existence of these arrangements to the holder (§2.7, §17.2). The adequacy of the arrangements is an input to every management review. The certification system holds no financial records; evidence of these arrangements is maintained outside it.

6.4.2 The relationship between money and decisions is fixed by this scheme and published at /fees: a fee buys evaluation, not a certificate; fees are agreed after the rabbinic decision and never in exchange for it; no person who sets or collects fees takes any part in a certification decision; a written quotation precedes any chargeable work; unannounced visits are inside the annual fee and never billed as extras, so that the fee schedule is never an incentive against making them; and no fee is ever charged for lodging a complaint or appeal, or for suspending or withdrawing a certificate — so that ending a certification always costs the body money and can never be softened for that reason.

6.4.3 No fee, quotation, invoice or payment is recorded in the certification system. There is no financial model in the data model at all. Financial administration is conducted outside it. This is stated so that no assessor or client expects a system record that does not exist; the separation rule in 6.4.2 is a requirement on persons and is evidenced by the fee file, not by software.

6.5 Non-discriminatory conditions

6.5.1 Emet's procedures are administered in a non-discriminatory manner (ISO/IEC 17065, 4.4.1, 4.4.2). Certification is open to any applicant whose products fall within what Emet is competent and staffed to assess. Access is never conditional on the size of the applicant, membership of any association or group, the number of certificates already held (4.4.3), or the use of any particular consultant or supplier. These conditions are published at /fees and undertaken to the holder in the agreement (§2.4).

6.5.2 Where Emet is not competent or not staffed to evaluate a product, process or designation, it declines the application in writing rather than take the fee. A refusal is recorded against the application with its reason, and the reason is sent to the applicant. Designations the body cannot presently supervise are not offered.

6.5.3 Emet confines its requirements, evaluation, review, decision and surveillance to matters specifically related to the scope of certification (ISO/IEC 17065, 4.4.4). In particular, Emet imposes no requirement of religious observance, affiliation or practice on the applicant, its owners or its personnel. What is assessed is the kosher status of products, ingredients, equipment and processes — nothing about the people who make them, except where a specific halachic requirement of a product or process (for example, supervision requirements determined by the Rav HaMachshir) turns on who performs an act of production; such requirements are product requirements, are stated in the certification requirements for that product, and are decided by the Rav HaMachshir.

7 Management of impartiality

7.1 Commitment

7.1.1 Certification activities are undertaken impartially (ISO/IEC 17065, 4.2.1), and top management is committed to that in a published policy at /impartiality (4.2.5). The policy's operative sentence is the scheme's rule: Emet certifies; it does not consult. Explaining a requirement and a finding to a client is certification; deciding for the client how to meet it is consultancy and is not offered at any price.

7.1.2 Commercial, financial and other pressures shall not compromise impartiality (4.2.2). Decisions rest solely on evidence of conformity and are never influenced by fees, ownership, client size or any other interest.

7.2 Prohibited activities

7.2.1 Emet, and any entity under its organisational control, does not design, manufacture, install, distribute or maintain any product it certifies, and does not provide consultancy — including recipe reformulation, sourcing of compliant suppliers, or construction of a client's kosher programme — to its clients (ISO/IEC 17065, 4.2.6). Nor does it certify any product or site for which it, its owners, or a company under its control have acted in any of those roles.

7.2.2 Emet's certification is not marketed or offered as linked with the activities of any consultancy, and no statement is made or permitted that certification would be simpler, faster or cheaper if a particular adviser were used (4.2.9).

7.3 Identification of risks — the risk register

7.3.1 Emet identifies risks to its impartiality on an ongoing basis, arising from its activities, its relationships, and the relationships of its personnel (ISO/IEC 17065, 4.2.3), and for each identified risk records how it is eliminated or minimised (4.2.4). The instrument is the impartiality risk register, an internal controlled document. It is deliberately not published: the standard requires the risks to be managed, not the related parties to be named in public. It is reviewed at every management review and whenever a new relationship is formed.

7.3.2 The register currently carries five standing entries, summarised here because a scheme that hides its own risk analysis from its assessor is not managing it:

a) A related certification business under common ownership. Managed under 4.2.7: a separate certification body is none of the roles prohibited by 4.2.6 and certifies different objects. Controls: separate legal entities, databases, certificates and staff records; no cross-marketing and no suggestion that one certification eases the other (4.2.9); the public sites do not reference each other; if the related business ever performs consultancy within the meaning of ISO/IEC 17065, 3.2 for a company that later applies to Emet, the 4.2.8 firewall applies and the 4.2.10 cooling-off period runs; and the owner is not the certification decision-maker on any file where the relationship bites — in practice the Rav HaMachshir decides, which the kashrut requires in any case. Residual risk is perception, and the register says so.

b) Fee dependence on a small number of clients. Controls are those of clause 6.4.2, plus reporting of client concentration at management review.

c) A single rabbinic authority. Controls: personal conflict declarations before touching a file; every determination recorded with its author, date and conditions verbatim; where the Rav HaMachshir has any relationship with an applicant, the file is declined rather than managed. Two qualifications belong here rather than in a footnote. First, the register names the decisions table as where determinations are recorded, and that table has no write path (clause 9.1.4) — so the recording control is a paper control today. Second, an open gap already stood in the register: a second competent rabbinic decision-maker is needed for continuity and so that an appeal against his decision can be resolved by someone else (ISO/IEC 17065, 7.13.5).

d) Concentration of functions in very few staff. The register records this plainly as an open nonconformity against ISO/IEC 17065, 7.5, 7.6 and 7.13.5: with a single operating staff account, evaluator and decision-maker are not separated in fact, and an appeal against a certificate that account worked cannot be resolved by anyone, because the software refuses it. No control is available until further personnel exist. This scheme does not pretend the separation is operating where it is not; clause 9.1.4 states the same fact from the structural side.

e) External pressure. Any attempt by a client, trade body or competitor to influence a certification outcome is recorded in the register and raised at management review, and no decision is made under it (4.2.11).

7.3.3 The register is a document, not data. The certification system holds no impartiality register, no conflict-of-interest declarations and no interest records as structured data. Declarations under clause 7.5 are made in writing and held in the personnel file. Bringing declarations into the system is planned; until then the paper record is the record.

7.4 Cooling-off

7.4.1 No person who has provided consultancy or been employed by a client shall be used to review or make a certification decision for that client, or to resolve a complaint or appeal concerning it, within two years of the end of that involvement (ISO/IEC 17065, 4.2.10; 7.13.6). This period is published in the impartiality policy and written into the certification agreement (§§2.3, 16.2). It is enforced by declaration and file assignment, not by software: the system's exclusion checks (clause 7.6.2) look only at recorded involvement in Emet's own process, and know nothing of a person's prior outside relationships. The declaration of clause 7.5 exists to surface exactly those.

7.5 Personal declarations

7.5.1 All personnel, internal or external, and any committee member who could influence a certification decision shall act impartially (ISO/IEC 17065, 4.2.12) and shall commit in writing to disclose any prior or present association with a supplier, designer, provider or operator to whose evaluation or certification they are assigned, and to reveal every situation known to them that may present a conflict of interest (6.1.3 b), c)) — before acting on a file. Where a declaration bites, the person is removed from the decision, not merely noted. Where no uninvolved competent person exists to replace them, the file is declined.

7.6 Mechanism for safeguarding impartiality

7.6.1 This scheme requires a formally documented mechanism for safeguarding impartiality, with balanced representation of significantly interested parties such that no single interest — Emet's own personnel counting as one interest — predominates; with access to all information necessary to its function; and with the right to take independent action if top management does not follow its input (ISO/IEC 17065, 5.2.1–5.2.4). Interested parties appropriate to this scheme include certified clients, customers of clients, rabbinic and communal representatives, and conformity-assessment expertise.

7.6.2 The mechanism is not yet constituted. No committee exists. Until it is constituted, the impartiality safeguards actually in operation are these, and the scheme states plainly which of them are running and which are written but dormant:

a) Running. On an appeal concerning a named certificate, any person who authored a revision on that certificate is refused the decision — the screen says so before the outcome is typed, and the refusal is re-checked when the button is pressed. The condition wording printed above the signatory's name cannot be edited in place: a change is a new version, the proposer must open a rendered specimen certificate before any decision is recorded against it, and the record must name the rav whose decision it is, the day he gave it and how it reached the office. Where the operator is not that rav's own account, the record and the audit trail both say the decision was recorded on his behalf. Every issued certificate is undeletable at the database level, and the audit trail is append-only against the runtime role.

b) Written but not yet operating. The rule that a person who made a certification decision on a certificate may not decide a complaint about it is implemented against the decision log — and the decision log has no write path (clause 9.1.4), so with no decision records the check can never fire. The rule that the requester of a change may never be its approver is implemented, but nothing in the system can create a change request, so it too is dormant. Both are recorded here as controls awaiting the write paths they depend on, not as controls in force.

c) Not a separation at all. The three staff roles ADMIN, REVIEWER and RAV are not partitioned by function. Recording a rabbinic decision on condition wording is open equally to all three, and the RAV role confers no capability that ADMIN and REVIEWER do not also hold. The role exists to link a person to the signatory row whose name a certificate prints; it is not, today, an enforcement boundary.

Constituting the mechanism is a precondition to any future claim that the structure of ISO/IEC 17065, clause 5 is met, and its absence is reviewed at every management review alongside register entry 7.3.2 d).

8 Confidentiality and publicly available information

8.1 Confidentiality obligations

8.1.1 Emet is responsible, through legally enforceable commitments, for the management of all information obtained or created during certification (ISO/IEC 17065, 4.5.1). The certification agreement (§12) carries the commitment on both sides and names the public register as the exception the holder consents to by accepting; a non-disclosure undertaking is exchanged at enquiry, before any formula or supplier information passes. That undertaking is a paper instrument — the system holds no record of it. All personnel, employed or contracted, are bound individually (6.1.1.3, 6.1.3).

8.1.2 The following are confidential by default and are never published: client ingredient lists, formulas, recipes and supplier identities (the facility Schedule A is a client's bill of materials); supplier letters of certification; inspection and visit reports; visit schedules and frequencies; plant-specific kashering protocols; fees and quotations; internal halachic reasoning behind a determination; complaint and appeal files; and the identity and movements of any mashgiach — the last treated as a matter of personal safety, not only of confidentiality. None of these is reachable from any public route in the system.

8.1.3 Where Emet is required by law to release confidential information, the client or person concerned is notified in advance of the information provided, unless the law prohibits the notification (ISO/IEC 17065, 4.5.2). Information about a client obtained from a source other than the client — a complainant, for example — is treated as confidential, and the source is protected (4.5.3).

8.2 The public register — what is published

8.2.1 Emet maintains a public, searchable register of certifications (ISO/IEC 17065, 7.8) at /register, searchable by certificate number, holder, product and public brand. The index lists the number, the holder, the count of published products, the validity end date and the current effective status. Each entry opens onto its own register page, which publishes: the certificate number; the holder's name and location; the certified facility, unless withheld under clause 8.3.1 c); the scheme; the validity dates and the original issue date; the current effective status with a plain-language explanation, and with the recorded reason and effective date on an adverse one; the products with their kosher classification and designations; the public brands; whether the mark is required on the product; the name of the signing authority, under the label Rav HaMachshir; the integrity code of the current document; and the full status history — issue, amendment, renewal, extension, reduction, suspension, reinstatement, withdrawal, ending — with the recorded reasons on suspension, withdrawal and ending. A certification voided as issued in error says so in its own words, distinct from a withdrawal. A certification ended by agreement is stated explicitly not to have been revoked.

Two things this scheme requires are not on the register page today, and are recorded as gaps rather than described as features. The written restoration conditions for a suspension are not published. They are held against the certificate, sent to the holder in the suspension notice, and shown to the holder in the client portal; the public page does not print them, so a buyer looking at a suspended certificate is told that supervision is paused but not what would end it. The signing authority's title is not printed beside the name. Both are display work on a page that already holds the data.

8.2.2 The register is the truth about status. Expiry is computed from the validity dates at the moment of reading, never stored, so no scheduled job stands between a certificate lapsing and the register saying so. A change of status appears the same day it is decided, and the printed certificate itself states, on its face, that it is valid only while shown as active on the Emet public register.

8.3 What a holder may withhold — and what it may not

8.3.1 Three withholdings are provided for, all at the holder's request and Emet's agreement:

a) A brand name may be marked confidential. The register then shows the product and its classification but not the brand, states explicitly that some brands are withheld, and gives the address at which Emet will confirm whether a specific labelled pack is covered; the brand is also excluded from register search, which is what withheld means. The certificate schedule prints a warning that the register shows fewer lines than the document. This control is operable — but only at the moment a brand is added. There is no interface to withdraw or apply confidentiality to a brand already recorded; a brand can only be withdrawn from the certificate altogether. Changing an existing brand's confidentiality requires direct database intervention under change control, and is recorded as a gap.

b) An entire product line may be marked confidential, suppressing it from the register and from register search while it remains on the certificate and on the holder's own document.

c) The facility may be withheld from publication — the co-packer case — so that the register names the holder but not the plant, says that the site is withheld at the holder's request, and gives the address at which Emet will confirm it to a rabbinic authority.

Withholdings b) and c) are honoured everywhere the register, the certificate renderer and the frozen snapshot read them, but no administrative interface exists to set them; today they can be effected only by direct database intervention under change control. This is recorded as a gap.

8.3.2 The following may never be withheld, by anyone, for any consideration: the existence of an issued certificate; its number, holder, scheme and validity dates; its current status; its status history; and the reasons recorded for a suspension or withdrawal. Confidentiality is for the client's trade secrets, not for the fact or the fate of a certification.

8.3.3 The register never publishes: ingredient information of any kind, findings, visit records, fees, or draft certificates — a draft does not exist publicly, and a verification query against one answers "never issued."

8.4 Verification

8.4.1 Every issued certificate carries a QR code resolving to /verify/{number} on both the certificate face and the schedule, and prints its document integrity code — the first eight hexadecimal characters of a SHA-256 over the frozen issue snapshot, set as two groups of four — on the face and in the schedule traceability line. Two distinct services read these, and the scheme does not blur them:

a) The number lookup, at /verify/{number} and by API. It answers from the register: status, explanation, dates, products, history. It reproduces the integrity code recorded against the current issue, so that a reader can compare it by eye with the code on the document in front of them; it does not itself judge the document presented. A number whose check character does not add up is answered as a mistyping and expressly not as a forgery — the page says so in terms. A well-formed number Emet never issued gets the strongest wording on the site. Lookups of well-formed numbers are logged with a hashed source address and one of five outcomes — active, suspended, withdrawn, expired, never issued — so that repeated probing of the numbering space is visible; a mistyped or unrecognised number is answered but is not logged.

b) The integrity check, at /verify/integrity. It takes the printed code rather than the number, finds the issue that code belongs to, recomputes the hash over the stored snapshot, and answers CURRENT; SUPERSEDED, naming the revision that replaced it, so that the holder of a genuine but earlier document is not told it is unknown; ALTERED, where the record no longer hashes to its own code; or UNKNOWN. This service does not log lookups.

8.5 Publicly available information

8.5.1 Emet maintains and makes available the information required by ISO/IEC 17065, 4.6: the rules and procedures for granting, maintaining, extending, reducing, suspending, withdrawing, ending by agreement and refusing certification, published in full at /scheme (4.6 a)); how the body is funded and what it charges for, at /fees (4.6 b)); the rights and duties of applicants and holders, including the restrictions on use of the mark and on references to certification, in the certification agreement, the mark usage guide and the public terms at /terms (4.6 c)); and the complaints and appeals procedure, at /complaints (4.6 d)). The public site further explains, in generic terms, the twelve stages of supervision, what an inspection covers, the unannounced-access policy (never the schedule), and the difference between allergen control and kashrut.

The rabbinic leadership is not named publicly. The site describes the Rav HaMachshir as a role and states that he alone decides; no page names the person. A name reaches the public only on an individual certificate's register page, where the signatory of that certificate is printed. Since clause 9.3.4 makes a named, verifiable and reachable rabbinic authority the market's first check on this body, naming him on the public site is a requirement of this scheme that is not yet met.

8.5.2 Every published halachic explanation is signed off by the Rav HaMachshir before publication; the market reads these pages as the body's psak, and no one else may author one.

8.5.3 The scheme's normative documents (EKS-01 to EKS-06) are drafted and not in force. None has yet received rabbinic approval; none is published as a normative document; and no certificate cites a normative document today. The one partial exception is EKS-06, whose content already ships to every holder as the mark usage guide inside the client pack and is incorporated into the agreement by §10.5 — but it ships as a usage guide, not as a cited normative document of the scheme.

This is a known nonconformity with the intent of ISO/IEC 17065, 7.1.2 and 7.7.1 d) read with 3.10, under which the scope of certification identifies the normative documents the product was judged against. It is accepted deliberately in preference to the worse alternative of publishing standards the body cannot yet enforce. The order of operations is fixed: the Rav HaMachshir approves a document, the staffing to apply it exists, and only then is it published and cited. Until EKS documents are in force, the requirements a certificate attests to are those of this scheme document and the conditions printed on the certificate face.

9 Organisational structure, personnel and resources for evaluation

9.1 Organisational structure

9.1.1 Certification activities are structured and managed so as to safeguard impartiality (ISO/IEC 17065, 5.1.1). Emet shall maintain a documented organisational structure showing duties, responsibilities and authorities of management and certification personnel and their relationship to evaluation, review and decision (5.1.2), and shall identify the persons having overall responsibility for each of the matters in 5.1.3 a)–n), including policy, finances, evaluation, review, certification decisions, contractual arrangements and complaint handling. If any rabbinic or technical committee is formed, formal rules for its appointment, terms of reference and operation shall exist, and the authority to appoint and dismiss its members is retained by the body (5.1.4).

9.1.2 The certification system recognises four roles: ADMIN, REVIEWER, RAV and CLIENT. Issuance of a certificate is restricted to ADMIN and executes inside a single transaction whose gates are: a client-approved revision; a certification agreement accepted at the current version; for a renewal, no open finding at the facility; and a named signing authority in the frozen snapshot. The dates are re-anchored at issue rather than taken from the draft, so a certificate cannot assert supervision from a day before anyone decided anything. Every issue writes a gapless internal ledger serial in the same transaction, and the database refuses deletion of any issued certificate.

Of these four roles, only ADMIN and CLIENT are enforcement boundaries. REVIEWER and RAV differ from ADMIN only in being barred from issuance and status change; the RAV role grants no capability that ADMIN and REVIEWER do not equally hold, including the recording of a rabbinic decision on condition wording. It marks who a person is, not what only they may do.

9.1.3 The functional separations this scheme requires are: intake and fees are administrative; ingredient, formula and process evaluation belongs to the evaluator; the review of an evaluated file belongs to a reviewer who did not evaluate it; the certification decision belongs to the Rav HaMachshir alone; and fees are set only after the decision. One person selling, inspecting and deciding is precisely the pattern this market distrusts, and the separations exist on paper for that reason as much as for ISO/IEC 17065, 7.5.1 and 7.6.2.

9.1.4 Two of these separations are not enforced by the system, and a third depends on a record that is never written. Nothing prevents the account that drafted a revision from issuing it. Nothing distinguishes the account that evaluated a file from the account that reviews it. And the decision log — the table designed to evidence that the decision-maker was a different person from the evaluator — has no write path in the application at all: no screen, action or module creates a decision record. Three consequences follow, and this scheme states each rather than describing a control that is not operating:

a) The rabbinic decision is evidenced today by the recorded condition-set attestation (clause 9.3.4) and the append-only audit trail, not by a decision record.

b) The impartiality risk register's own control under entry 7.3.2 c) — "decisions recorded with their author, date and conditions verbatim" — is a paper control, not a system one.

c) The complaint-side exclusion rule of clause 7.6.2 b), which asks whether the person deciding a complaint made the certification decision, reads that empty table and therefore never excludes anybody.

All of this is recorded as the open nonconformity in register entry 7.3.2 d). Until additional personnel and the decision write-path exist, the separation of evaluation from decision is a rule kept by people and evidenced on paper. The published site states that whoever evaluates does not decide; that statement is true of how the body works and is not yet true of what the software enforces, and closing that distance is the first system obligation this clause creates.

9.2 Management of competence

9.2.1 Emet shall employ, or have access under legally enforceable agreement to, sufficient personnel for its operations (ISO/IEC 17065, 6.1.1.1), each competent for the functions they perform (6.1.1.2). A documented procedure shall determine competence criteria per function, identify and provide training, demonstrate competence before use, formally authorise each person for each function, and monitor performance (6.1.2.1 a)–e)); the records of 6.1.2.2 a)–h) shall be kept for every person involved in the certification process, contracted mashgichim included, and every such person shall sign the 6.1.3 contract committing to confidentiality, independence from commercial pressure, and disclosure of any prior or present association with a client assigned to them.

9.2.2 No competence, qualification, training or authorisation record exists in the certification system. There is no personnel model; a visiting mashgiach appears in a visit record as a typed name, and the signatory record carries an identity — name, Hebrew name, title, authority, tenure — not a competence file. The records of 9.2.1 are therefore kept as controlled documents outside the system. A mashgiach registry and per-function authorisation records are planned system work; until they exist, the paper file is the record and this clause is the requirement it is audited against.

9.3 The functions and their distinct competences

9.3.1 The mashgiach (Rabbinic Field Representative). The eyes of the body in the plant. Competence criteria: personal religious qualification as determined by the Rav HaMachshir — a mashgiach must be a personally observant, shomer-Shabbat Jew, and the body answers its staffing model honestly rather than blurring this; trained command of the inspection walk — receiving against the approved ingredient list, storage and segregation, production against the declared process, shared equipment and changeover status, the distinction between caustic CIP (cleaning) and kashering, steam and utilities, rework, the laboratory and pilot plant, and the label store; the ability to keep allergen control and kashrut apart (an allergen-validated dairy-free line can be halachically dairy); and the discipline to record findings with severity and required corrective action. The system supports the last of these directly: a visit is recorded against the facility with its date, its supervisor, whether it was unannounced and its attachments, and each finding carries a severity, a corrective action, a due date and its closure. The mashgiach observes, verifies and reports; the mashgiach does not determine kosher status and does not decide certification. The mashgiach's identity and movements are never published (clause 8.1.2).

9.3.2 The evaluator (Rabbinic Coordinator). Conducts the determination stage: ingredient and formula review, and equipment and process review — the latter jointly with the Rav HaMachshir on anything shared or heated. Competence criteria: food technology and ingredient chemistry sufficient to read a specification sheet and a flow diagram; command of the letter-of-certification discipline — a letter is verified against the exact producing plant, the exact item code, the claimed status and its expiry, because a letter that says Dairy kills a Pareve claim; knowledge of which certifying agencies Emet accepts and why; and command of the facility-scoped approval rule — the same lecithin can be approved at plant A and unapproved at plant B, and no approval is ever global.

The system supports this function directly: the per-facility Schedule A with statuses (pending, approved, restricted to source, rejected, innocuous), each decided status stamped with its decider and refused by the database without one; a restriction that cannot be recorded without writing the restriction down; supplier letters as records with number, claimed status, verifier and expiry, superseded and never overwritten; approval refused against any agency not marked accepted; and a database constraint that physically prevents an ingredient approved at one facility from being attached to a product certified at another.

Two limits belong in the same paragraph. The expiry of a letter does not change anything by itself: the nightly sweep counts letters expiring within sixty days into a staff alert, and nothing in the system withdraws or downgrades an approval when its letter lapses. The rule that an expired letter means an unapproved ingredient — which the public site states — is kept by people acting on that alert. And the change-request object that is supposed to gate substitutions on a live certificate cannot be created (clause 7.6.2 b)), so the "nothing substituted without prior written approval" rule reaches the database only for links that are made through it, and reaches everything else on paper.

9.3.3 The reviewer. Conducts the review of ISO/IEC 17065, 7.5: a person not involved in the evaluation of the file, competent to judge whether the evaluation record is sufficient to put before the decision-maker — that every product is classified (the system refuses acceptance of an application unless a classification is chosen for every product, and defaults nothing, because an unmarked product declares itself pareve), that the ingredient position is complete, that findings are closed or honestly open, and that the file's scope is what the applicant thinks it is. The reviewer's competence is of the record, not the plant: enough kashrut and process knowledge to know when the record is thin, and the independence to say so. That independence is a rule kept by people; the system does not yet know who evaluated a file and therefore cannot refuse them the review (clause 9.1.4).

9.3.4 The Rav HaMachshir. The rabbinic authority of the body and the certification decision-maker. Competence criteria: recognised rabbinic ordination with authority in the relevant areas of halacha; and named, verifiable, reachable and genuinely in charge — the market's first and heaviest check, and the one this body does not yet pass in public (clause 8.5.1).

He alone decides whether to certify, to certify with conditions, or to decline, and he alone decides suspension, reduction, withdrawal and reinstatement. He alone determines the kashering protocol for a given item of equipment, the supervision requirements that attach to a designation, and the words a certificate prints about what may be eaten.

Two records evidence him in the system today. The signatory record carries his name, Hebrew name, title, authority, tenure and signature, and a certificate cannot be issued unless a named signing authority is frozen into its snapshot. The condition-set attestation carries his ruling on the four sentences printed above his name: they are append-only, so what any certificate was issued under can always be read back; they cannot be adopted by anyone who has not first opened them on a rendered specimen certificate; and adopting one requires naming the rav whose decision it is, the day he gave it and how it reached the office, with the record and the audit trail marking it as recorded on his behalf whenever the operator is not his own account. A ruling more than ninety days old must be reconfirmed before it can be printed.

Neither record is a decision log, and the system holds no other evidence that the person who decided was not the person who evaluated. That is the gap of clause 9.1.4, and it is his gap before it is anybody's: the credibility of every certificate this body issues rests on a separation that is, today, kept by people and written on paper.

Part III — The certification process

11. Application

11.1 Emet makes its services accessible to all applicants whose activities fall within the scope of its operations, and access is not conditional on the size of the client, on membership of any association or group, or on the number of certifications already issued (ISO/IEC 17065, 4.4.2, 4.4.3). Emet obtains through the application all information necessary to complete the certification process under this scheme (ISO/IEC 17065, 7.2).

11.2 An application is made in one of two ways, and the record states which:

11.2.1 through the public application form, which is rate-limited and protected against automated submission — a submission that trips the automation check is flagged for staff attention on the record itself, never silently discarded; or

11.2.2 opened by Emet staff on the applicant's behalf, in which case the record identifies the staff member as the actor, so an application typed by the office is never mistaken for one made by the client.

11.3 Each application is assigned a sequential internal reference of the form SR-YYYY-NNNN. The reference is internal to the certification process: it is given to the applicant as their handle on the file, and it is never a certificate number, never printed on a certificate, and never published on the register (certificate numbers are non-sequential — see 16.4).

11.4 The application shall state:

a) the legal name of the applicant, its trading name where different, its commercial registration number, and its address; b) the production facility (site) for which certification is sought. Certification under this scheme is granted per facility, not per company: the same product made at a second site is a separate application; c) every product for which certification is sought, and the brand names under which each will be sold; d) the scheme applied for — standard, or the seasonal Passover scheme; e) the name and contact details of the person acting for the applicant.

The system records each application as a company, site, application, and per-product records, so that the facility is a distinct object from the first day (an ingredient approval, an inspection finding and a certificate all attach to the facility, not the company). Implementation note: neither the public form nor the staff intake form collects a trading name, and the commercial registration number is optional in both. The trading-name field exists in the data model and on the certificate template, and nothing writes it, so no certificate has ever printed one. Both are obtained by the office and, until the forms carry them, are not part of the structured record.

11.5 The scheme further requires of the applicant, before evaluation begins: a description of the production process; identification of any outsourced process or co-packing arrangement affecting conformity; and the ingredient list for each product, with the producer and producing plant of each ingredient (ISO/IEC 17065, 7.2 Note 1). Implementation note: the application form does not yet collect process descriptions, outsourcing declarations or ingredient lists as structured data, and the system currently has no facility for the applicant — or for staff — to upload any document at all: the only files the system ever writes are the certificate PDFs it generates itself. This information is obtained by the office during intake and entered by staff (ingredients directly into the facility's Schedule A — see 13.2). Until an upload path exists, documentary evidence supplied by the applicant is held in the office file and is referenced, not stored, in the system record. This is a known gap against the record-keeping intent of ISO/IEC 17065, 7.12.1.

11.6 The scheme classifies each application into a risk category on intake — cold pareve production, heated production, dairy, shared-line, meat — because the depth of evaluation and the later surveillance intensity follow from it. Implementation note: the risk-category field exists in the data model and no line of application code reads or writes it; classification is presently a judgement made and recorded outside the system. Not yet implemented.

11.7 An application concerning an existing certification (extension of scope, change of facility) follows the same intake. Implementation note: the data model provides for linking an application to an existing certificate, and no workflow writes that link; today every accepted application opens a new certification file. Drafts of kind EXTENSION and REDUCTION can be opened against an issued certificate, but nothing in the system can add a product to an issued certificate or remove one from it — no screen creates or retires a certified-product row after acceptance. Extension and reduction of an issued scope are therefore not operable end-to-end (see 13.9 and Part IV on changes).

11.8 Information obtained at application — above all ingredient lists, formulas and supplier identities — is confidential and is never published. The certification agreement (agreement §12) binds this in contract from the moment a client accepts it; an application that is rejected, or one still in evaluation, is covered by Emet's own confidentiality undertaking rather than by a signed agreement, because the agreement is sent per certificate and accepted only at the point of issue (see 15.3 b). The public register discloses only what Part IV, section 17 of this scheme states it discloses.

12. Application review

12.1 Before any evaluation begins, Emet reviews the application to confirm that the information is sufficient, that any difference in understanding between Emet and the applicant is resolved, that the scope sought is defined, that the means to perform the evaluation are available, and that Emet has the competence and capability to perform the certification (ISO/IEC 17065, 7.3.1). The review concludes in one of two recorded acts: acceptance or rejection.

12.2 Acceptance is an explicit action by a staff reviewer, and the system enforces its minimum content:

a) every product on the application must be individually classified — pareve, dairy or meat — before acceptance can complete. There is no default classification; a product nobody classified throws, and nothing is created; b) the reviewer may correct the declared brand names at this point; c) the reviewer must name the signatory — the Rav HaMachshir under whose authority the file will proceed. An application cannot be accepted into evaluation with no rabbinic authority attached. Implementation note: the signatory is chosen from the signatories table, whose rows can be created only by the seed script or by a command-line script — no screen creates one. The seed writes a placeholder named "— to be appointed —", and the system will accept that placeholder as an answer. Appointing the rav and replacing that row is an office act with no software gate behind it.

12.3 Rejection requires a written reason, which is recorded on the application and emailed to the applicant (ISO/IEC 17065, 7.6.6 applied at the earliest gate). A rejection with no stated reason cannot be recorded.

12.4 The scope of certification sought shall be defined at review (ISO/IEC 17065, 7.3.1 c). Under this scheme the scope is the set of classified products, their brands and designations at the named facility, and it is this set that the evaluation addresses and the certificate later states. Implementation note: a free-text scope description field exists, is not written by any workflow, and is not printed on any document. The scheme treats the structured product list as the scope of record.

12.5 Where an application presents a product type, a process technology or a designation with which Emet has no prior experience, Emet shall determine before acceptance whether it has the competence and capability for all required activities, shall keep a record of the justification for proceeding, and shall decline the application where it lacks any required competence (ISO/IEC 17065, 7.3.2–7.3.4). This rule has particular force in kashrut: designations Emet cannot staff — Cholov Yisroel, Pas Yisroel, Glatt, wine, meat slaughter — are declined, not improvised. Implementation note: this determination is not supported by any system function. There is no personnel, competence or authorisation model anywhere in the data model; the only record of a person is a login account with a role. The determination is performed and recorded as an office record. Not implemented in software.

12.6 Where Emet relies on a certification it has already granted — for example, an ingredient produced at a facility Emet itself certifies — to omit any evaluation activity, the existing certification is referenced in the file, and the justification is provided to the client on request (ISO/IEC 17065, 7.3.5). Implementation note: there is no field or workflow for recording such reliance; the reference and the justification are office records.

13. Evaluation

13.1 Evaluation covers everything the scope requires and nothing certification does not (ISO/IEC 17065, 7.4.4; 4.4.4). It comprises: the ingredient-by-ingredient review (13.2–13.4), the plant inspection (13.5–13.7), sampling where ordered (13.8), and the kashrut-specific controls (13.9). Emet plans the evaluation activities for each file so that all necessary arrangements — access, timing during production, personnel — are made before work begins (ISO/IEC 17065, 7.4.1, 7.4.2). Implementation note: the evaluation plan is an office document; the system models no evaluation task and no assignment of one to a person.

The ingredient review (Schedule A)

13.2 Every ingredient, processing aid and rework input of every product in scope is reviewed individually and recorded in the facility's approved-ingredient list ("Schedule A"). Approval is facility-scoped, never global: an ingredient is identified by its name, its producer, the specific producing plant, and the item code, and the database keys it on exactly that tuple within one site, so an approval at one facility confers nothing at another. The same lecithin may be approved at plant A and stand rejected at plant B.

13.3 Each ingredient carries exactly one of five recorded statuses: PENDING (not yet decided), APPROVED, RESTRICTED_TO_SOURCE, REJECTED, or INNOCUOUS (acceptable from any source as a category — a status that is itself a rabbinic determination, not a chemist's). A restriction to source cannot be recorded without the restriction being written down. Every decision stamps the identity of the decider and the time; a database check constraint refuses any row that is not PENDING and carries no reviewer and no review time, so no path exists by which an ingredient acquires a status anonymously.

13.4 An ingredient relying on another agency's certification is evidenced by that agency's letter of certification (LOC), recorded with its letter number, the status the letter claims (pareve, dairy, dairy equipment, meat, fish), its expiry date, and the identity of the Emet staff member who verified it. The controls on this evidence are:

a) the letter must cover the exact producing plant, the exact item code, and the claimed status. A letter that certifies the producer but not the plant, or that says "kosher" where the recipe requires pareve, does not support the approval. Whether a Dairy or Dairy-Equipment claim is compatible with the product using the ingredient is a determination of the rabbinic reviewer. Implementation note: this control is entirely manual, and the data to automate it is not captured — the letter record carries a status claim, a number and an expiry date, and has no field for the plant or the item code the letter covers. Matching the letter to the plant and the item code is done by a person reading the letter against the screen. Not implemented; b) an approval may rest only on an agency Emet accepts. Where an agency is attached to an ingredient, the system refuses to record APPROVED or RESTRICTED_TO_SOURCE unless that agency is marked accepted. The list of accepted agencies is a standing rabbinic determination of the Rav HaMachshir; entries on that list can be created only by direct database administration — no screen adds an agency or flips the accepted flag — and this is a gap; c) a new letter supersedes the old and never overwrites it. Recording a letter stamps every previous letter on that ingredient as superseded and inserts a new row, so the evidentiary history of every ingredient remains readable for the life of the file; d) expiry is tracked. The nightly sweep counts letters expiring within sixty days and mails staff; the Schedule A screen for a facility marks each individual ingredient whose live letter is expiring or already expired. An expired letter removes the evidentiary basis of the approval and the scheme requires the ingredient to be re-evidenced or the approval withdrawn — the system does not change the ingredient's status when a letter lapses, and flagging of affected products is not implemented at all, because nothing in the application writes the ingredient-to-product link; e) the letter document itself cannot be attached to the record — the file reference field exists and nothing writes it. There is no upload path anywhere in the system. Until one exists, the physical or emailed letter is held in the office file. This is a gap against ISO/IEC 17065, 7.4.9 and 7.12.1, and its closure is a priority of the scheme.

The plant inspection

13.5 The initial evaluation includes an inspection of the facility during production. The inspection presumes, and verifies where relevant to the kashrut determination, the baseline of good hygiene practice in Codex CXC 1-1969: the design of facilities and equipment such that surfaces can be effectively cleaned, and storage that permits incompatible materials to be segregated (CXC 1-1969, Section 9); maintenance, cleaning and disinfection regimes and their monitoring (Section 11); control of operation, including product and process descriptions, raw-material specifications and incoming-material control (Section 13, in particular 13.1.1, 13.1.2, 13.2.3 and 13.2.8); and, where the establishment operates one, its HACCP-based controls (CXC 1-1969, sections 16 to 19). Emet does not certify hygiene and its certificate asserts nothing about food safety; the Codex baseline matters to this scheme because kashrut controls — segregation, changeover, kashering — are only as reliable as the plant's underlying discipline of cleaning, identification and record-keeping.

13.6 The inspection walks, as a minimum:

a) receiving — whether materials on the dock and in the receiving records match the facility's Schedule A, by producer, plant and item code, not by trade name alone; b) storage and segregation — the physical separation of approved from unapproved materials, and of dairy from pareve materials, in warehousing and staging (cf. CXC 1-1969, Section 9 on storage that allows incompatible materials to be segregated); c) production against the declared process — that the process observed is the process evaluated, including processing aids and rework; d) shared equipment and changeover — the inventory of lines and equipment, their kashrut status, and what happens between incompatible runs (see 13.9.1 and 13.9.4); e) steam and utilities — shared steam, CIP circuits and heat-transfer media, which can carry status between nominally separate lines; f) rework — the origin, status and routing of reworked product; g) the laboratory and pilot plant — where unapproved materials commonly enter a facility; h) the label store — that mark-bearing packaging exists only for products in scope and is controlled.

The finding that a facility's allergen controls are validated is noted but is never treated as evidence of kashrut status: an allergen-clean line can be halachically dairy, and "may contain" statements are allergen artifacts that say nothing either way.

13.7 The record of an inspection comprises the visit — date, who attended, whether the visit was announced or unannounced, and narrative notes — and its findings (see 13.10). Visits are recorded against the facility and not against the certificate, deliberately: every certificate at that facility shares the inspection history, because the plant, not the paper, is what was inspected. Inspection records are never published; nothing in the public register or the verification service exposes a visit or a finding. Implementation note: the visit record is four fields plus free text and its findings. A structured inspection checklist, a report template, and photographic or documentary attachments are not implemented — the attachment relation exists in the data model and no upload path writes it. The person who attended is recorded as a typed name, not as a person the system knows, which is the personnel gap acknowledged in Part II. The identity and movements of inspection personnel are confidential as a matter of personal safety and are never published.

Sampling

13.8 Where the nature of a product or a doubt arising in evaluation warrants it, the Rav HaMachshir may order sampling and analysis — for example, species or dairy-residue analysis. A certification scheme is required to define the extent to which sampling is required and on what basis, when it is required, and who is permitted to undertake it (ISO/IEC 17067, 6.5.2). Under this scheme sampling is ordered case by case on the Rav's instruction, is taken by Emet's inspector or by a laboratory Emet names, and the taking of the sample and its chain of custody are recorded before any result is relied on. Analytical results inform, and never replace, the rabbinic determination: a negative residue result does not itself make equipment pareve. Implementation note: no sampling, testing or laboratory-result function exists in the system, and no sampling has formed part of any evaluation. This clause states a provision of the scheme, not a current operation, and until it is exercised the scheme's answers to 6.5.2 are untested. Emet's public material must not describe sampling as something it currently does.

Kashrut-specific controls

13.9 The following determinations are rabbinic. In each, the scheme fixes the process — what is examined, what is recorded, who is told — and the ruling itself belongs to the Rav HaMachshir. Nothing in this document, and nothing in the software, constitutes a halachic ruling.

13.9.1 Equipment status. Every line and every significant item of shared equipment is assigned a kashrut status by the Rav or under his standing instructions: pareve, dairy, meat, or not kosher pending kashering. The evaluation records the line inventory and the status of each. Implementation note: there is no equipment or line registry in the data model at all; the inventory is held in the inspection notes and the office file. Not implemented.

13.9.2 Kashering. Whether equipment requires kashering, and by what method, is the Rav's determination for the specific equipment and its history of use. Where kashering is required it is performed in the presence of Emet's inspector, and the record states the equipment, the method, the date and the supervising rabbi. A caustic clean-in-place cycle is cleaning; whether any cleaning or heating regime constitutes kashering is never assumed from the plant's sanitation records and is decided only by the Rav. Implementation note: there is no kashering event log in the data model; kashering performed during evaluation is recorded in the visit notes. Not implemented.

13.9.3 Segregation of dairy and pareve production. Where a facility runs both dairy and pareve products, the evaluation establishes and the certificate's scope depends on: the physical or temporal separation of the runs; the status of every shared vessel, line and utility; the changeover regime between a dairy run and a pareve run and whether that regime, in the Rav's determination, restores pareve status or merely cleans; and the controls preventing dairy ingredients from entering the pareve room. A pareve designation is a positive claim — the plain mark, carrying no suffix, asserts pareve, and the artwork generator refuses to default to it (see Part IV on the mark) — and it is granted only where these controls support it.

13.9.4 Cleaning between runs. For every pair of incompatible runs the evaluation records what the changeover consists of and what status the Rav assigns to the line after it. The default of the scheme is conservative: an undetermined changeover leaves the line with the status of its last use. Implementation note: as with 13.9.1, there is no structured place to record this; it lives in the visit notes.

13.9.5 Passover. Passover certification is a separate scheme, not an annotation. Its determinations — chametz, kitniyos handling, the status of equipment used in year-round production, the production window — belong to the Rav, and a Passover certificate expires with the festival season it covers: the system computes the window from the Hebrew calendar and ends it on the last day of Pesach, never twelve months from issue. Every standard-scheme certificate states its Passover status explicitly on its face, because silence would be read as fitness (see 16.3). Implementation note: the Passover scheme exists in the system as a distinct scheme with its own validity rule, and no Passover condition wording has ever been written or approved. Two things follow, and it is worth being exact about which is which. First, the system refuses to draft any certificate under a scheme that has no approved-and-active conditions set at all — and none exists for Passover — so a Passover certificate cannot be drafted today. Second, the renderer independently refuses to print a Passover sheet carrying the standard scheme's "Not certified for Passover" line, because that would deny under the title what the title asserts. Neither guard checks whether a rav approved the wording: the standard scheme's seeded wording carries no rav's decision and drafts without complaint (see 15.2). The scheme does not claim that the software enforces rabbinic approval of wording; it claims only that Passover cannot issue, and that is the current state.

Nonconformities and documentation of results

13.10 Every nonconformity found in evaluation is recorded as a finding with a severity (minor, major, critical), a description, the corrective action required, and a due date — the system requires all four — and the client shall be informed of all of them (ISO/IEC 17065, 7.4.6). Where the client wishes to continue, Emet provides information on the additional evaluation tasks needed, and the additional evaluation follows the same process as the original (7.4.7–7.4.8). A finding is closed only with a written closure note stating how closure was verified; findings are never deleted, and an open finding has a consequence the system enforces — it blocks issuance of a renewal at that facility (see 15.3 d). Implementation note: informing the client is not implemented. The system sends the client mail on four events only — application received, application decided, certificate issued, certificate status changed — and a finding is not among them. Communicating findings, and communicating the additional evaluation required, is done by the office outside the system and evidenced in the office file. This is an open gap against 7.4.6 and 7.4.7.

13.11 The results of all evaluation activities are documented before review (ISO/IEC 17065, 7.4.9). Implementation note: the documented results today are the Schedule A statuses with their letters, the visit and finding records, and the office file. Because no document can be uploaded, part of the evidence base necessarily lives in the office file rather than the system; clause 11.5's gap applies to the whole evaluation record and is restated here deliberately.

14. Review of evaluation results

14.1 Before any certification decision, at least one person who did not perform the evaluation reviews all information and results related to it, and the recommendation for a decision is documented (ISO/IEC 17065, 7.5.1, 7.5.2). Under this scheme the review confirms: that every ingredient of every product in scope has a decided, non-rejected status resting on current evidence; that the inspection is complete and its critical and major findings are closed or their disposition is stated; that the classification and designations claimed are the ones the evidence supports; and that the file is fit to be put to the Rav HaMachshir.

14.2 Implementation status, stated plainly. The system does not enforce this separation, and the review recommendation is not a recorded object: the decisions table designed to hold the rabbinic decision exists in the data model, is read by the certificate screen, and is written by nothing — not one line of application code creates a row in it. Nothing prevents the person who prepared a draft from also issuing it. The review of evaluation results is therefore presently a procedural requirement on the body, performed and evidenced in the office file and the audit trail, not a control the software guarantees. Emet's internal impartiality risk register records this, together with the underlying staffing constraint, as an open nonconformity against ISO/IEC 17065, 7.5, 7.6 and 7.13.5. It is the scheme's first-ranked implementation priority, and no statement anywhere in Emet's public material may claim the separation is system-enforced, or state it as an unqualified fact, until it is. Emet's public scheme page presently carries such a statement; it is a defect against this clause and is to be corrected.

15. Certification decision

15.1 Emet is responsible for, and retains authority over, its certification decisions (ISO/IEC 17065, 7.6.1). The decision to certify is the decision of the Rav HaMachshir: every kashrut determination the certificate embodies — the designations granted, the conditions stated, the acceptability of every ingredient path — is his, and no certificate issues without a named signatory on the document. Commercial staff take no part in the decision, and fees are agreed only after it, never traded against it. Implementation note: what the software enforces is narrower than what this clause requires. It refuses to issue a draft that carries no signatory name (15.3 c), and it records the rav's decision on the printed conditions (15.2); it does not know who decided to certify, and the decision record that would hold that is unwritten (14.2). The seeded signatory row is the literal placeholder "— to be appointed —", and the issue gate would accept it. That commercial staff take no part, and that fees follow the decision, are governance commitments of the body evidenced in the impartiality risk register and at /fees — not software controls.

15.2 The conditions decision. The two condition lines printed on every certificate — composed from four mandatory clauses: what the mark's presence means, the Passover status, the cholov standard applied to dairy, and what the sheet alone does and does not prove — are a rabbinic statement printed directly above the signatory's name. The system records this decision rather than performing it, and the record is strict:

a) wording is proposed with a written reason of at least ten characters, is validated (each clause 8–90 characters, no control characters, no clause empty — silence in any slot is read as a claim), and is versioned append-only: a revision rejects the prior proposal and inserts the next version, so the wording any certificate issued under can always be read back. A proposal identical to the wording in force is refused; b) before recording approval, the operator must have opened that exact wording on a rendered specimen certificate — the approval is refused unless the preview was taken by the same account; c) the approval names the Rav whose decision it is, the date he gave it, and how it reached the office (in person, by telephone, by email, in writing — a closed list). A future date is refused; a decision more than ninety days old is refused until reconfirmed. A database check constraint refuses any activated set that names no signatory, no date and no means; d) when the recording operator is not the Rav's own account, the record carries that fact and both the wording page and the certificate's conditions panel print "recorded on their behalf by —"; e) one set is active per scheme, enforced by a partial unique index; a certificate-scoped set, approved the same way, overrides the scheme set for that certificate (a wholly cholov-yisroel plant must not carry a blanket cholov-stam line); f) approval logs into the audit trail how many certificates are already in circulation under the older wording; deciding whether to reissue them is a separate act.

The seeded wording predating this control is marked as originating from seed data — nobody's decision — and both screens that show it say so until the Rav's adoption of it is recorded. That seeded wording is nonetheless ACTIVE, and certificates draft and issue under it. The software's guard is that a scheme must have some active wording, not that a rav approved it; the guard against issuing unapproved words is this clause, on the body.

15.3 Issue gates. Issuance is a single database transaction and refuses to complete unless all of the following hold:

a) the draft revision has been approved by the client — the client sees and approves the exact document, bound to that revision by a single-use link, before it can issue. No staff route sets a revision to approved; b) the certification agreement has been accepted, and accepted at its current version: acceptance of an earlier version is not acceptance of this one (ISO/IEC 17065, 7.7.3 c); c) a Rav HaMachshir is named on the draft as signatory — a certificate with no rav behind it asserts an opinion no person has given. The check is that a name is present, not that the name is a real appointment; d) for a renewal, no corrective action is open at the facility.

15.4 Dating. Validity is anchored to the day of the decision, not the day the draft was typed: a draft written on Monday and issued on Friday asserts supervision from Friday, and a draft prints no dates at all for exactly this reason (see 16.6). The sole exception is renewal, whose window is anchored to the end of the cycle it continues, so that a renewal decided early does not shorten, and one decided late does not stretch, the certification cycle. The date of grant never precedes the date of decision (ISO/IEC 17065, 7.7.1 b).

15.5 Refusal. A decision not to certify is recorded with its reasons and notified to the applicant (ISO/IEC 17065, 7.6.6). The applicant may resume from evaluation after addressing them.

15.6 The issuance ledger. Every issuance writes, in the same transaction, a gapless serially-numbered ledger entry recording the certificate, its number, cycle and issuing actor. The serial comes from a single continuous counter that is never partitioned by year. The ledger is a completeness proof — no certificate can exist without a ledger line, nor a ledger line without its certificate — and the nightly sweep raises a critical alert if the counter and the ledger ever disagree.

15.7 Separation of decision from evaluation. The scheme requires that the person deciding took no part in the evaluation (ISO/IEC 17065, 7.6.2) and is bound to Emet by employment or contract (7.6.3). The current implementation status is as stated in 14.2: the requirement stands on the body and is not enforced by the software. The rabbinic decision itself is at present evidenced by the audit trail and the recorded conditions attestation, not by a dedicated decision record; closing that gap closes 14.2's with it.

16. Certification documentation

16.1 On issue, Emet provides the client with the certificate and its schedule (ISO/IEC 17065, 7.7.1). The certificate as printed states: Emet's legal name and full postal address, its website and its email, in the footer of every sheet; the holder's legal name, and beneath it a line carrying the trading name and commercial registry number where those are recorded, together with the holder's city and country; the production facility — its owner company, the site name where that differs, and the site's street address, city and country, printed in full, the renderer refusing to print a truncated address and failing loudly instead; the scheme, in the title; the products with their brands, classification (pareve, dairy, meat) and designations, one row per product-and-brand, with the status column refusing to shrink or truncate a designation; the two condition lines (15.2); the certificate number; the validity window; and the signature block — the Rav HaMachshir's name, Hebrew name, title and authority, above an electronic-signature statement carrying the date and the document's integrity code (ISO/IEC 17065, 7.7.2). Page one carries a QR code resolving to the public verification page for that number, the integrity code (16.5), and a traceability line naming the number, the revision and the date of issue.

Implementation note — three stated shortfalls. (i) The certificate does not print the holder's street address, only city and country. (ii) It does not print the original issue date or the certification cycle number, although both are frozen into the record at issue; a reader cannot tell from the sheet how long the holder has been certified or which cycle this is. (iii) The document-control line naming the form and its revision is printed only when the certificate has schedule pages; a certificate whose products fit on the face carries no document-control line at all. All three are defects against 7.7.1 and against Emet's own document-control rule, and their correction is a change to the certificate template.

16.2 Where the product table overflows, it continues on schedule pages that carry the same certificate number, the mark, the holder's name, the same two condition lines, their own QR code to the register, their own page-of-page numbering, the document-control line for the schedule form, and — where any product line or brand is withheld from the public register — an explicit warning that the register will show fewer lines than the paper, so that the difference is never read as forgery. Implementation note: schedule pages do not carry the integrity code; it prints on page one only. A reader holding only a schedule page can reach the register but cannot check the code.

16.3 No condition slot is ever blank. A certificate that is silent on Passover looks fit for Passover; one silent on the cholov standard is taken by the stricter reader as one they may rely on; an unmarked pack, absent the mark-dependence line, inherits the certification. The four statements are therefore mandatory on every certificate, in wording approved under 15.2, and the renderer refuses to print a certificate whose frozen record carries no conditions at all.

16.4 The certificate number is one unbroken token: the fixed prefix EMET followed by a seven-character core — six random characters and a trailing check character, in Crockford base32 (no I, L, O or U), with any core containing an unfortunate word discarded and redrawn. A database check constraint holds the shape. The number encodes nothing — no country, no year, no sequence — because a number kept for the life of a certification must not embed anything that can change, and a sequence would publish both the size of the register and the order of its clients. Typing tolerance is deliberate: the parser accepts spaces, dashes, lower case and the Crockford foldings, and a number of the right shape whose check character fails is answered "check your typing", never "never issued". The number is minted at first issue and is kept for life: renewal keeps the number and the row; only the cycle and the window move.

16.5 What is frozen at issue, and the integrity code. The complete content of the certificate — holder, facility, every product with its brands, the print label of every designation as worded that day, the condition lines with the identity, version and origin of the approved set that produced them, the signatory, the dates, the cycle, the verification URL — is frozen at issue as a versioned snapshot, and the PDF is rendered from the frozen snapshot, never from live database rows. A later change to any master data changes no document already issued. The integrity code printed on the sheet is the first eight hexadecimal characters of the SHA-256 of the canonical serialization of that snapshot, printed as two groups (for example 7F3A·92C1). Verification recomputes the hash over the stored bytes exactly as stored and answers one of: current, superseded (a genuine earlier version, with the revision it belongs to and the revision now in force), altered (the code was found but the record no longer hashes to it), or unknown. Stored snapshots are never rewritten — an old snapshot shape is upgraded in memory only — because rewriting one byte would silently turn every printed code on every circulating copy into an apparent forgery.

16.6 A draft is unmistakable: a red band across the head of every page, a diagonal watermark reading DRAFT — NOT VALID FOR USE, an unissued seal, no number anywhere including the PDF's own title, no dates — the validity rule is stated in words instead — and no QR code. A draft answers "never issued" on verification, because no number exists to look up. Nothing that has not been decided can be mistaken for something that has.

16.7 Certification documentation issues only after, or concurrent with, the decision, the fulfilment of certification requirements, and the completed agreement (ISO/IEC 17065, 7.7.3) — enforced as the transaction gates of 15.3.

16.8 The certificate remains Emet's property, is reproduced only in full, and is valid only while the public register says it is (agreement §9). All three are printed in the footer of every issued sheet. The register and verification service are described in Part IV, section 17.

16.9 Normative reference — a stated gap. ISO/IEC 17065, 7.7.1 d) requires the formal certification documentation to convey or permit identification of the scope of certification, and 3.10 defines that scope as including the standards and other normative documents, with their date of publication, to which conformity is judged (see also 7.1.2). Emet's kashrut standards (EKS-01 through EKS-06) are drafted and are not in force: none has yet been approved by the Rav HaMachshir, and no certificate may cite a document he has not approved. Until they are in force, Emet's certificates identify the scheme and the rabbinic authority but cite no normative document. The scheme records this plainly as an open gap; its closure — rabbinic approval of the EKS documents, publication, and the addition of the citation to the frozen certificate content — is a precondition of any claim that this Part is fully aligned with ISO/IEC 17065, 7.7.

Part IV — Maintaining certification

17. The public register and verification

(ISO/IEC 17065 clause 7.8; ISO/IEC 17067 clause 6.5.1 q))

17.1 Emet maintains a public register of certified products. The register is the single authoritative statement of what Emet certifies: a certificate document is valid only while the register shows the certification in force, the certificate itself prints that rule on its face, and the certification agreement (clause 9.3) binds the holder to it. Where a document in circulation and the register disagree, the register prevails.

17.2 The register is published on Emet's website and is searchable by certificate number, holder name, product name and public brand name. Each certification also has a dedicated verification page addressed by its certificate number; the QR code printed on the face of every certificate and on every schedule page resolves to that page. This satisfies, and exceeds, the minimum in ISO/IEC 17065 clause 7.8 that validity be confirmed to anyone on request; Emet additionally confirms validity by correspondence when asked.

17.3 The verification page for each certification publishes: the certificate number; the holder's name and its city and country; the certified facility and its address; the scheme (standard or Passover); the date of issue, the original date of first issue, and the expiry date; the date of the most recent amendment; the certified products, each with its classification (pareve, dairy or meat), its designations, and its published brand names; whether the mark is required on the product; the name of the Rav HaMachshir who stands behind the certification; the document integrity code; the current status with a plain-language explanation of what that status means for product in the market; and the status history of the certification, newest first. The status history is published deliberately: a register that shows only a current status would allow a certification to be quietly suspended and reinstated with no public trace. The register's search listing itself shows number, holder, product count, expiry and status; the full record is on the verification page.

Not yet implemented: the published history carries the recorded reason for a suspension, a withdrawal and a termination, but not for a reduction of scope — a reduction currently appears in the history without its reason. The scheme requires a reason on every adverse change, and this is recorded as a gap. The register also publishes the Rav HaMachshir's name without his title, and names the facility by its owner company rather than by the site's own name.

17.4 ISO/IEC 17065 clause 7.8 b) requires the register to identify the standard or other normative document to which conformity has been certified. The register identifies the scheme; it does not yet cite a normative document, because the Emet kashrut standards (EKS-01 through EKS-06) are drafted and not yet in force. Until they are adopted and published, this is an open gap against clause 7.8 b) and clause 7.7.1, and is recorded as such. On adoption, the register and the certificate shall each cite the applicable EKS document and its dated version.

17.5 A register entry has exactly one of five effective statuses: valid, suspended, withdrawn, terminated, or expired. Expiry is computed at the moment of each lookup from the expiry date on record — it is never a stored flag flipped by a scheduled job — so the register cannot show a lapsed certification as valid during any processing window. A certification is treated as valid through the end of its expiry date and expired from the following day.

17.6 The register distinguishes states that other registers blur, because the difference is material to the holder's reputation:

a) a withdrawn certification is stated to be permanently revoked, with the instruction that product bearing the mark under that number is not certified; b) a terminated certification is stated to have ended by agreement, with the express statement that nothing was found against the holder; c) a certification withdrawn because Emet issued it in error is published under its own wording: that the number was voided, never represented a valid certification, and that any document bearing it should be reported. A number is never reused — the minter checks every number ever issued, including voided ones, and the database refuses outright to delete an issued certificate — so the register must carry the distinction in words; d) a suspended certification publishes the fact of the suspension and the recorded reason.

Not yet implemented: the restoration plan (clause 21.4) is not published on the register. It is written when the suspension is recorded, sent to the holder in the suspension notice, and shown in the holder's own portal, but the public page and the verification API omit it. The scheme requires it to be public, so that a buyer can see what stands between a suspended supplier and reinstatement, and this is recorded as a gap.

17.7 A number Emet has never issued is answered in the strongest terms: that no such certificate has ever been issued. That sentence is the scheme's forgery detector, and two safeguards protect it. First, every certificate number carries a check character, and a lookup gives three separate answers, not two: a number that fails its check character, or that is not of Emet's shape at all, is answered "that is not a valid Emet number — check your typing", explicitly and in those words not a statement that the certificate is fake. Only a well-formed, checksum-valid number absent from the register reaches the never-issued answer. Second, draft certificates are not discoverable through the register under any circumstances: a certificate has no number until the moment of issue, so a draft answers as never issued, because a draft asserts nothing.

Not yet implemented: number parsing folds case, whitespace and the ASCII hyphen, and the Crockford confusions (O for 0, I or L for 1). It does not fold typographic dashes; a number pasted with an en dash falls to the "not a valid Emet number" answer rather than resolving. That is safe — it never reads as a forgery accusation — but it is a lookup that should have succeeded, and is recorded as a gap.

17.8 Every certificate carries a printed integrity code: the leading digits of a cryptographic hash (SHA-256) of the certification data frozen at the moment of issue. The verification service accepts an integrity code and answers with one of four verdicts: the document is the current issue; it is an authentic but superseded issue, with the date it was superseded; the record it points to has been altered and no longer matches its own code; or the code is unknown. The hash is recomputed from the stored frozen record at every check — the stored code is looked up but never trusted on its own. A superseded document is answered as authentic-but-superseded rather than unknown, because the holder of a genuine older document must not be told their document is a forgery.

17.9 The register withholds, by design: ingredient lists and supplier information (the approved-ingredient schedule is a client's bill of materials and is confidential under the certification agreement, section 12); inspection visits, findings and corrective actions; fees; and all drafts. A brand name the holder has designated confidential is omitted, and the affected product line is flagged on the register as having brands withheld, so the register never silently implies completeness; the certificate the holder holds lists every brand, and the schedule page says in terms that some lines are withheld online.

Not yet implemented: the data model carries a flag for withholding an entire product line and a flag for withholding the identity of a certified facility, and the register and the certificate both honour them. Neither flag can be set by any screen — no staff page and no client route writes either — so in practice both are permanently off. Until an interface exists, a request to withhold a product or a facility cannot be given effect at all, and this is recorded as a gap.

17.10 A verification lookup of a well-formed certificate number is logged with its outcome (found active, found suspended, found withdrawn, found expired, or never issued) and a privacy-preserving hashed identifier in place of the requester's address. The log exists so that a surge of lookups against a number Emet never issued — the signature of a document circulating fraudulently — is visible to Emet (ISO/IEC 17067 clause 6.5.12); the staff analytics screen reports the count of never-issued lookups and the numbers most often hunted.

Not yet implemented: two things this clause needs are missing. A mistyped or unrecognised input is not logged at all, so a forger's near-miss attempts leave no trace. And lookups against a withdrawn number are recorded but surfaced on no screen — the outcome is stored and never reported, so a surge against a revoked certificate would not be seen. Both are recorded as gaps.

18. Surveillance

(ISO/IEC 17065 clause 7.9; ISO/IEC 17067 clauses 5.3.7, 6.5.7)

18.1 The scheme is designed as a type 5 scheme in the sense of ISO/IEC 17067 clause 5.3.7: initial evaluation of the ingredients, the production process and the facility, followed by ongoing periodic assessment of the production process together with periodic sampling of product, with the mark licensed for ongoing production. Because continuing use of the mark on product is authorised, surveillance is mandatory, not optional (ISO/IEC 17065 clause 7.9.3). The certification agreement (clause 8.2) makes the right to use the mark rest expressly on surveillance.

Not yet implemented: only the process-assessment limb of the type is operating. The sampling limb — which clause 5.3.7 makes part of what a type 5 scheme is — has no record in the system (clause 18.8). Until it does, Emet does not claim to be operating a complete type 5 scheme, and this is recorded as a gap.

18.2 Frequency. The frequency and intensity of surveillance are set per facility according to risk, considering at least: whether production is cold or heated; whether the facility handles dairy or meat; whether certified products share equipment with uncertified production; the facility's finding history; and the sensitivity of the ingredient base (ISO/IEC 17067 clause 6.5.7 — nature of the product, consequence and probability of nonconformity). Visit schedules and frequencies are never published and are not disclosed to the holder beyond what an announced visit requires; the public process page says so.

Not yet implemented: the software records visits after the fact but does not hold the surveillance programme itself — there is no per-facility frequency, no next-visit-due date, and no alert when a visit falls overdue. The application carries a risk-category field, and no code anywhere writes it or reads it; it is presently dead. Until the programme module exists, the surveillance calendar and the risk category are maintained by the Rabbinic Coordinator outside the system, and this clause operates as a documented manual procedure. This is recorded as a gap to be closed.

18.3 Announced and unannounced visits. Surveillance comprises both announced and unannounced visits. The certification agreement (clauses 5.1–5.6) secures Emet's right of access during production hours without prior notice, including at any co-packer, and including access for observers and for complaint investigation. Every recorded visit states whether it was unannounced, together with the date, the supervising inspector, who recorded it, and free-text notes of what was examined. The balance of announced to unannounced visits at a given facility is a risk decision under clause 18.2 and is never disclosed.

18.4 What a surveillance visit examines. A visit assesses the production process against the certified state of the facility, covering as applicable:

a) receiving — that incoming materials match the facility's approved-ingredient schedule by producing plant, item code and status claim, and that documentation of incoming materials is maintained (Codex CXC 1-1969, section 13.2.8); b) storage and segregation — that certified and uncertified, and dairy and pareve, materials are separated physically or by validated practice; the discipline is analogous to allergen cross-contact control (Codex CXC 1-1969, section 13.2.7), but the two are not the same: allergen validation says nothing about kosher status, and segregation adequacy for kashrut is judged on halachic criteria; c) production — that the process run matches the declared process, including processing aids and rework; d) shared equipment and changeover — the kashrut status of each line and the changeover regime between statuses; e) cleaning versus kashering — maintenance and cleaning per Codex CXC 1-1969 section 11.1, with the express caution that a chemical cleaning regime is cleaning, not kashering; whether any given regime constitutes valid kashering of equipment is a halachic determination that belongs to the Rav HaMachshir, and the visit records the facts for that determination rather than making it; f) utilities — steam and water in contact with product (Codex CXC 1-1969, section 13.3); g) the label store — that only approved mark-bearing artwork is in use, on the products it was approved for (certification agreement clause 10.4), and lot identification sufficient for traceability and recall (Codex CXC 1-1969, sections 14.1 and 13.5).

Not yet implemented: none of a) to g) is a structured record. A visit stores a single free-text note, so the system cannot show that a particular limb was examined on a particular visit, and cannot report across visits on any of them. The checklist above is a written procedure the mashgiach works to; making it a record is a gap to be closed.

18.5 Findings. Every nonconformity observed at a visit is recorded as a finding with a severity of minor, major or critical, a description, the corrective action required, and a due date — all four are required by the software, not optional. A finding is closed only with a written closure note recording the evidence of correction; there is no delete path, and the database refuses to remove a visit a finding hangs from. Corrective actions past their due date are reported to staff by an automated nightly review, which also reports supplier certification letters expiring within sixty days.

Not yet implemented: the agreement (clause 8.3) and ISO/IEC 17065 clause 7.9.2 require that a decision arising from a finding be taken by persons uninvolved in raising it. The finding record does not capture who raised it, and closing a finding does not compare the closer against the raiser, so the system neither enforces that separation nor evidences it. This is recorded as a gap.

18.6 Visits and findings attach to the facility, not to an individual certificate, by design: every certification at a facility rests on the same physical reality, and a finding at the plant is a fact against all of them. The consequence is enforced at renewal: no renewal may be issued for any certification at a facility while any finding at that facility remains open (clause 20.6).

18.7 Surveillance falling overdue. If surveillance cannot be completed — because access is refused, visits cannot be scheduled, or anything else on the holder's side — the basis of the mark licence lapses (certification agreement clause 8.2) and the certification is liable to suspension under section 21, with refusal of access an enumerated ground. No suspension occurs automatically: the decision is taken by a person under section 21, on the record of the attempts made. Not yet implemented: because the system does not compute visit due dates (clause 18.2), it cannot flag lapsed surveillance on its own; detection is presently the Rabbinic Coordinator's manual responsibility.

18.8 Sampling and testing. ISO/IEC 17065 clause 7.9.3 requires periodic surveillance of marked products, and the certification agreement (clauses 5.4 and 8.1) secures Emet's right to take and examine samples at the facility. The scheme requires ingredient and label spot-checks during visits, and reserves market sampling of marked product. Not yet implemented: no sampling record, laboratory result or market-check record exists in the system; sampling performed at visits is recorded only inside a visit's free-text note. A structured sampling record is a gap to be closed before surveillance can be said to satisfy clause 7.9.3, or before the scheme can be described as type 5 in full (clause 18.1).

19. Changes affecting certification

(ISO/IEC 17065 clause 7.10; certification agreement sections 6 and 15)

19.1 The governing rule is prior notification: the holder must tell Emet before implementing any change to an ingredient, a supplier, a formulation, a processing aid, shared equipment, the production method, the place of manufacture, or any packaging that carries the mark (certification agreement clause 6.1). Approval is never retrospective. Product affected by an unapproved change is outside the certification until Emet says otherwise. Changes the holder cannot hold back — ownership, legal or trading name, the persons responsible for production, insolvency, litigation touching certified products, loss of an operating licence — must be notified without delay (clause 6.2). A holder unsure whether a change matters is obliged to ask (clause 6.3).

19.2 On any notified change, Emet decides the appropriate action per ISO/IEC 17065 clause 7.10.2, drawing as required on evaluation, review, decision and revised certification documentation (clause 7.10.3). Clause 7.10.3 requires the rationale for omitting any of those activities to be recorded. Not yet implemented: the system has no field and no record for that rationale; it exists only in correspondence held in the certification file, and cannot be produced from the system on demand. This is recorded as a gap.

19.3 A new ingredient. No ingredient enters certified production before it is approved on the facility's approved-ingredient schedule (Schedule A). Approval is facility-scoped and keyed to the exact producing plant, item code and status claim — never global, because the same ingredient can be acceptable from one plant and not another; the database enforces the facility scope through paired composite foreign keys. An approval may be restricted to a named source, and the software refuses a restricted approval that does not state the restriction. Innocuous ingredients may be designated acceptable from any source; that designation is itself a rabbinic determination and stamps the person who made it. Where an approval names another kashrut agency, the software refuses to approve it unless that agency is on Emet's accepted list. Letters of certification are recorded as documents with the producing plant, the item code, the claimed status (pareve, dairy, dairy equipment, meat, fish) and an expiry date; a new letter supersedes its predecessor rather than overwriting it, so the approval history is permanent, and letters approaching expiry are reported automatically (clause 18.5).

Not yet implemented: four things this clause describes are not enforced or not possible. a) The letter document itself cannot be attached to the record. The schema carries the file relation and no screen fills it, so what is stored is the letter's particulars typed in, never the letter. b) Nothing requires a letter to exist, or to be unexpired, before an ingredient is approved. An approval can be recorded against no letter at all. c) The dairy-versus-pareve cross-check — the examination of a letter's status claim against the use, where a dairy claim defeats a pareve product — is performed by the reviewer, not the software. d) The table that links an approved ingredient to the certified products using it exists, with its facility pin, and no code anywhere writes a row to it. Until it is populated, the system cannot answer "which certified products use this ingredient", which is the question b) and c) both turn on. Until these are closed, ingredient approval is a documented manual procedure with a partial record, and any doubtful case is referred to the Rav HaMachshir, whose determination is final.

19.4 A new supplier. A change of supplier for an existing ingredient is a new approval, not an amendment of the old one: the approval key includes the producer and producing plant, so the same item from a different source has no approved status until evaluated under clause 19.3.

19.5 A change of plant. Certification attaches to a named facility. A change in the place of manufacture — in whole, in part, or by engagement of a co-packer — requires evaluation of the new facility as at initial certification: ingredient schedule (approvals do not transfer between facilities), equipment and process review, kashering where required, and inspection. The Rav HaMachshir decides whether and on what conditions the certification extends to the new facility. The holder must secure Emet's access rights at any co-packer before certification of that production (agreement clause 5.6). Not yet implemented: the facility named on a certificate cannot be changed by any screen, and there is no workflow for adding a second facility; a change of plant is presently handled as a new application.

19.6 A change of formulation. A reformulation, including a change of processing aid, is notified before implementation and assessed against the approved-ingredient schedule and the product's certified classification. Where the change could alter the classification — pareve to dairy being the paradigm case — the determination is the Rav HaMachshir's. A confirmed classification change is executed on the certificate record through the two-step reclassification workflow, which states in plain words what each choice means before it is committed, strips any designation that cannot survive the new classification, and writes an audit event naming the old and new state. Because the register reads product classification live, the change is public immediately; the issued certificate is unaffected until the next revision, and the screen says so. A reformulation may require a revised certificate under clause 19.9.

19.7 A change of ownership. Certification is not transferable. On a change of ownership or of legal identity, Emet reviews whether the certified state of production persists — same facility, same process, same responsible persons — and the certification agreement must be re-accepted by the new legal person before any further issue, since the obligations on which every sanction rests must bind the entity that now holds the certificate. Where continuity of production is not established, the change is treated as a new application. A holder that ceases to exist without a successor is terminated under section 21.

Not yet implemented: none of this is enforced. There is no ownership-change workflow; the holder company recorded against a certificate is never changed by any code path; and nothing resets the certificate's agreement acceptance, so the issue gate would read the old entity's acceptance as satisfying the new one. Until a workflow exists, a change of ownership must be handled as a new certification, and this is recorded as a gap.

19.8 Recording change requests. The data model provides a change-request record (ingredient addition or substitution, supplier change, formula change, new product, equipment change, other) with a decision, a decision note, and a rule enforced in software that the person who raised a request cannot decide it. Not yet implemented: no screen — client portal or staff — can create a change-request record; the decision workflow exists and nothing feeds it. Notified changes are presently handled by staff acting directly on the ingredient schedule and the certificate record, with the notification retained in correspondence. The scheme requires the change-request channel to be opened to holders; until then this clause operates as a documented manual procedure and is recorded as a gap.

19.9 Revised certification documentation. Changes that alter what the certificate says are executed as certificate revisions: amendment (content corrected or updated), extension (scope grown) or reduction (scope shrunk). Every revision is drafted from a frozen snapshot, approved by the client against the rendered document, and issued under the issue gates of clause 20.6; superseded revisions remain answerable through the integrity service as authentic-but-superseded (clause 17.8). An extension or a reduction moves what is covered, never the validity window.

Not yet implemented: products cannot be added to or removed from a certification after the application is accepted — the only code that creates a certified product is the acceptance step. Extension and reduction therefore exist as revision kinds and dating rules with no scope-change workflow behind them, and the register's published event stream records an extension or a reduction under the generic issue event rather than as what it is. Scope changes are presently effected only by opening a new application, and this is recorded as a gap.

19.10 Changes to the requirements of the scheme. When Emet changes the scheme's requirements in a way that affects holders, it notifies every affected holder in writing — what changed, what the holder must do, and by when — and verifies implementation (ISO/IEC 17065 clause 7.10.1; agreement section 15). The software enforces that no certificate may be issued or renewed unless the holder has accepted the current version of the certification agreement — acceptance of an earlier version does not carry forward, because the obligations a sanction rests on have to be the obligations the holder actually saw. A holder that cannot or will not implement a change by the stated date is reduced, suspended or terminated under section 21 (agreement clause 15.3).

Not yet implemented, and blocking: there is no way to put a new agreement version to a holder who has already accepted an earlier one. Sending the agreement is refused once acceptance is recorded, and the staff screen hides the control in that state. Combined with the issue gate above, publishing a new agreement version would make every existing certification unrenewable with no route out. Until a re-acceptance path exists, the agreement version must not be changed. This is the highest-priority gap in this Part.

19.11 Changes to the conditions printed on certificates. The four condition statements printed on every certificate and on every schedule page (mark dependence, Passover status, milk-supervision standard, and the proof caveat) are governed data. Wording is changed only by an append-only revision: a proposal with a written reason, then activation recorded as a decision of the Rav HaMachshir — naming the deciding signatory, the date the decision was given, and the channel by which it reached the office; a decision more than ninety days old, or dated in the future, is refused, and the operator must have opened the rendered specimen certificate before activating. Where the operator is not the signatory, the record states that it was recorded on behalf of the signatory, and the screens repeat it. Re-proposing the wording already in force is refused as a change that changes nothing, and a separate route exists for a rav to adopt existing wording unchanged. The activation record notes how many certificates are in circulation under the older wording, so the decision to re-issue them is taken consciously. The substance of any such condition — what milk standard is required, what Passover status means — is a rabbinic ruling and belongs to the Rav HaMachshir; the scheme governs only how the ruling is recorded, printed and superseded.

20. The certification cycle and renewal

(ISO/IEC 17065 clauses 7.9.2, 7.4–7.7; ISO/IEC 17067 clause 5.3.7)

20.1 A standard certification runs for a cycle of twelve months, from the date of the certification decision to the day before its anniversary. A Passover certification is seasonal: it covers one Pesach only, and expires with the last day of the festival, not one day more. Passover dates are computed from the Hebrew calendar, never typed by hand.

20.2 The validity window is anchored to the decision, not the draft: however long a draft circulated before issue, the certificate asserts supervision from the date the decision was taken, and the dates are re-derived at the moment of issue rather than taken from the draft. The one exception is renewal (clause 20.4).

20.3 A certification is one record for life. Renewal does not create a new certificate: the number is retained, the original date of first issue never changes, and the cycle number increments. The register therefore shows the continuous history of a certification across every cycle (clause 17.3).

20.4 A renewal's validity window is anchored to the end of the cycle it continues — the new period begins the day after the previous expiry — not to the date the renewal happens to be issued. Renewing early costs the holder nothing and gains Emet nothing; the anchor removes any incentive on either side to game the date.

20.5 Renewal is a re-evaluation, not a formality (ISO/IEC 17065 clause 7.9.2, applying 7.4 through 7.6). At each renewal the scheme requires: re-verification that every supplier certification letter on the facility's approved-ingredient schedule is current — expiring letters are surfaced automatically sixty days out; reconciliation of the certified product list against actual production; and re-inspection of the facility.

Not yet implemented: the rabbinic decision itself has no record. The data model carries a decisions table, kept separate from the certificate precisely so that deciding can be shown to be a different act by a different person, and no production code path writes a row to it. What the system actually records at a grant or a renewal is the signatory frozen into the certificate's snapshot, and an audit event naming the administrator who operated the issue. Issuing is gated on the administrator role, and a rav's own account cannot issue at all. So the certificate names the Rav HaMachshir and the system holds no record of his decision, distinct from the office act that printed it. Recording the decision — as the conditions module already does for the wording (clause 19.11) — is the second-priority gap in this Part. Reconciliation of the product list against actual production likewise has no record.

20.6 No renewal (and no issue of any kind) occurs unless, enforced in software within a single transaction: the draft has been approved by the client against the rendered document; the certification agreement is accepted at its current version (clause 19.10); a named Rav HaMachshir stands on the draft; and — for renewal specifically — no corrective action at the facility remains open. An open finding blocks renewal of every certification at that facility until it is closed with evidence (clause 18.6). The transaction also mints the number, renders the document from the frozen snapshot, stores the file with its hash, and writes the gapless internal issuance serial, so none of those can exist without the others.

20.7 A certification not renewed by its expiry date shows on the register as expired from the following day, computed at lookup (clause 17.5); staff are notified of the lapse the next morning by the automated review. There is no grace period: product made after expiry is not covered. A late renewal restores the certification with its window still anchored to the previous cycle's end, and production in the interval remains uncovered. Whether kashrut consequences follow for product made in a lapse — and whether any of it may be treated as certified retrospectively — is not a question the scheme can answer; approval is never retrospective (clause 19.1).

Not yet implemented: the register does not record that a certification stood expired. Because expiry is derived and never written as an event, and because the renewed window is anchored to the day after the previous expiry, the published dates read as an unbroken period. The only public trace of a lapse is that the renewal event is dated later than the day the renewed period begins, which a reader must infer. The scheme requires the lapse to be stated, and this is recorded as a gap.

20.8 Records are retained by reference to the cycle: see clause 22.2.

21. Suspension, reduction, withdrawal and termination

(ISO/IEC 17065 clause 7.11; certification agreement section 13)

21.1 When a nonconformity with certification requirements is substantiated — through surveillance, a complaint, or otherwise — Emet decides among the responses of ISO/IEC 17065 clause 7.11.1: continuation under stated conditions (such as increased surveillance), reduction of scope to remove the failing products, suspension pending corrective action, or withdrawal. The decision is proportionate to the finding, comes to the holder in writing with its reasons and with the route to appeal it, and where the substance of the nonconformity is halachic — whether an ingredient, a process or a product remains kosher — the determination underlying it belongs to the Rav HaMachshir. No adverse status change is automatic: every one is a compare-and-set operation performed by a named administrator and written to the audit trail with its reason.

Not yet implemented: only two of the four responses have an operating path. Suspension, reinstatement, withdrawal and termination can be recorded; continuation under stated conditions and reduction of scope cannot. Continuation under conditions has no record of any kind, and reduction inherits the scope-change gap of clause 19.9. Both are recorded as gaps.

21.2 Every status change requires a written reason, which the software and the database both refuse to do without, and which is published on the register with the event. A reason category drives the register's public wording, so that a withdrawal for cause, a termination by agreement, and a voided mis-issue are never blurred (clause 17.6). The enumerated categories are: use of an unapproved ingredient; use of an unapproved label; undisclosed production; refusal of access; mislabelling; non-payment; the client's own request; cessation of production; issuance in error; and other (stated in full). Not yet implemented: the category is required by the interface only on a withdrawal and a termination — the two where the public wording turns on it — and is optional on a suspension, and optional on the server in every case. The scheme requires a category on every adverse change, and this is recorded as a gap.

21.3 The lawful transitions, enforced in software as compare-and-set operations that fail rather than overwrite: an active certification may be suspended; a suspended certification may be reinstated to active; an active or suspended certification may be withdrawn or terminated. Nothing ever leaves withdrawn or terminated. A certification that ended is re-granted, if at all, as a new certification — never resurrected — because otherwise the register could not be trusted about what was true on a given day. The database refuses outright, by trigger, to delete an issued certificate.

21.4 Suspension. A suspension cannot be recorded without a written restoration plan: the actions that end the suspension and restore certification, formulated and communicated by competent persons (ISO/IEC 17065 clause 7.11.4). The plan is sent to the holder in the suspension notice and shown in their portal; it is not yet on the public register (clause 17.6). While suspended: the register states that supervision is paused and that product made during the suspension is not covered; the holder must stop applying the mark to the suspended products and stop advertising their certification at once, and carry out the actions in the notice (agreement clause 13.2). Product lawfully marked before the suspension may continue to be sold unless the notice says otherwise. The notice states the period within which the suspension must be resolved; a suspension not resolved within it becomes reduction or withdrawal. Not yet implemented: the resolution period is not a field. It exists only inside the free text of the reason or the restoration plan, so nothing can compute it, report on it, or escalate on it; escalation on an expired suspension period is a decision under clause 21.1 taken from a diary kept outside the system.

21.5 Reinstatement. A suspension is lifted only after verification that the notified actions were completed; any evaluation, review or decision needed is performed under the applicable parts of ISO/IEC 17065 clauses 7.4–7.6 (clause 7.11.5), and the register is corrected so that the indications show the certification in force again (clause 7.11.6). Emet goes further than the standard requires: the suspension, its reason and its lifting remain permanently in the published history (clause 17.3), because a register that erases a suspension on reinstatement tells a buyer less than it knows. If reinstatement is conditioned on a reduced scope, clause 21.7 applies.

21.6 Withdrawal. On withdrawal the certification ends permanently. The register states that the certification has been revoked and must no longer be used or displayed, with its reason category. The holder must return the certificate, cease all use of the mark and all advertising at once, and within thirty days destroy or surrender unused packaging, labels and films bearing the mark, certifying this in writing (agreement clause 13.3) — and the withdrawal notice the system sends states those obligations in terms. Finished product lawfully marked while the certification was valid may sell through normal channels — unless Emet determines its kosher status is affected, in which case the holder must cooperate fully with corrective action including recall, over-labelling or public notice (Codex CXC 1-1969, section 13.5).

21.7 Reduction. On reduction Emet issues a corrected certificate and schedule, and the holder brings every claim, label and use of the mark within the reduced scope at once; for the removed products the holder's withdrawal obligations apply as if those products' certification had been withdrawn (agreement clause 13.4). The register and all public information are corrected so the reduced scope is unambiguous (ISO/IEC 17065 clause 7.11.3).

Not yet implemented: reduction has no operating path at all. Products cannot be removed from a certification (clause 19.9), so a corrected schedule cannot be produced; there is no reduction control on the status screen, and the reduction event is not published to the register as a reduction. Until the scope-change workflow exists, the only responses Emet can actually execute against a failing product line are suspension or withdrawal of the whole certification — which is disproportionate in exactly the case clause 7.11.1 b) exists to handle. This is the third-priority gap in this Part.

22 Records, retention and complaints and appeals

(ISO/IEC 17065:2012, 7.12 and 7.13; ISO/IEC 17067:2013, 6.5.1 t) and v), 6.5.5; Codex CXC 1-1969, section 13.4)

22.1 Records

22.1.1 Emet retains records to demonstrate how each certification was granted and maintained (ISO/IEC 17065:2012, 7.12.1). The records of the certification process, and where each lives in the system:

• The audit trail (audit_events) — every material act: an application accepted, a draft sent, an agreement accepted, a certificate issued, a status changed, a case opened and decided. Each event records the entity, the action, the from- and to-state, the reason where one is required, the actor by type and name, and the moment. This is the record of who did what, when.
• The certification record (certificates) — one row per certification for life (clause 20.3), carrying the holder, the facility, the dates, the cycle number, the current status with its reason and category, the restoration plan on a suspension, and the full evidence of the agreement's acceptance — version, acceptor, moment, address of origin, and the exact clauses the holder was sent, frozen at that moment.
• The issue snapshot (certificate_revisions) — every issue and every draft, each with the complete certification data frozen as issued, the rendered document, and the client's approval evidence: who approved, when, from where, and by which one-time link. Superseded revisions are retained, which is what lets the integrity service answer authentic but superseded rather than unknown (clause 17.8).
• The decision record (decisions) — the table built to hold the rabbinic decision distinct from the office act that executed it.
• The case record (cases) — every complaint and appeal, tracked to its conclusion (clause 22.6).
• The visit record (supervision_visits and its findings) — every recorded inspection and every nonconformity, with corrective action and closure evidence (clause 18.5).
• The correspondence record (outbound_emails) — one row per message the system sent or failed to send. For a certification body this is evidence, not a log: a suspension the holder was never told of is, for every practical purpose, a decision that did not happen. A message that carried a one-time link stores no body, so the mail record can never become a ring of working keys.
• The lookup record (verification_lookups) — every well-formed verification query with its outcome and a hashed source identifier (clause 17.10).
• The file store (stored_files) — every stored document: draft and final certificates, application uploads, visit attachments, artwork. Each row records a SHA-256 taken at the moment of writing; the bytes live in the storage directory and are re-hashed against the record at every weekly restore drill.
• The token record (access_tokens) — hashed credentials only, never the token itself. Session rows are deleted on sign-out and on revocation, deliberately: a session is a key, not evidence. The durable trace of what a link was used for is copied onto the record it acted on — a client approval writes the token's identity onto the revision row it approved.
• The issuance ledger (issuance_ledger) — one strictly gapless internal serial per issuance, written in the same transaction as the issue, providing the completeness proof that nothing was ever issued off the record.

22.1.2 The evidence classes are append-only, and the enforcement is structural, not procedural. The application connects to the database as a runtime role that is not the owner of any table; that role has had UPDATE, DELETE and TRUNCATE revoked on the audit trail, the file store, the decision record and the issuance ledger, so no code path — including a compromised one — can rewrite or remove them. The correspondence record is split at the column: the identity half (who was written to, about what) is write-once, and the runtime role holds an update grant listing only the delivery-state columns. The case record cannot be deleted or truncated, though its own columns remain updatable so a case can move forward; it is therefore protected against destruction but is not immutable in the way the audit trail is. Findings, ingredient approvals, supplier-letter records, artwork and change requests cannot be deleted. An issued certificate can never be deleted at all: a database trigger refuses the operation outright, whoever asks (clause 21.3). The lookup record alone is append-only by behaviour rather than by grant — no code alters it, but the database would permit it — and this is recorded as a hardening gap.

22.1.3 ISO/IEC 17065:2012, 7.12.1 requires records demonstrating that all certification process requirements have been fulfilled. The scheme states plainly which records a certification decision rests on that the system cannot presently hold, each established in its own section: the rabbinic decision itself — the decisions table exists, append-only, and no production code path writes a row to it (clause 20.5); the non-disclosure undertaking exchanged at enquiry, which is a paper instrument (clause 8.1.1); the supplier letter of certification as a document — its particulars are typed in, the letter itself cannot be attached (clause 19.3); the structured content of an inspection, which is one free-text note (clause 18.4); any sampling or laboratory result (clause 18.8); the surveillance programme and its frequencies (clause 18.2); and the recorded rationale for omitting evaluation activities on a change (clause 19.2, against 7.10.3, which routes its record through 7.12). The internal halachic reasoning behind a determination of the Rav HaMachshir is different in kind: it is deliberately not recorded in the system at all (clause 8.1.2) — the record holds the determination and its provenance, never the reasoning. Until the listed gaps are closed, Emet's records demonstrate most of the process, and this clause is the honest inventory of the remainder.

22.2 Retention

22.2.1 The scheme runs on an annual re-evaluation cycle, so ISO/IEC 17065:2012, 7.12.3 sets the floor at the current and the previous cycle, and ISO/IEC 17067:2013, 6.5.1 v) requires the scheme to define retention. The certification agreement (§14) carries the same floor on both sides: Emet keeps the records demonstrating the certification for at least the current and previous cycle, and the holder keeps the records the scheme requires of it — ingredients, suppliers, production, cleaning and kosherization, label approvals, and its complaints record — for at least the same period. The scheme sets its actual periods well above that floor, per class:

• Permanent, never destroyed: the certification record, every issue snapshot and rendered document, the issuance ledger, the audit trail, the decision record, the case record and the correspondence record. Permanence here is not caution but necessity: the register promises that a number is never reused and that a voided number can be explained forever (clause 17.6 c), and that promise is only as good as the records behind it.
• Evaluation and surveillance records (applications and their uploads, visit records, findings, the approved-ingredient history, supplier-letter records): for the life of the certification and no less than seven years after it ends — and in no case less than the shelf-life of any product certified under it, applying the principle of Codex CXC 1-1969, section 13.4, that records outlive the product they vouch for, because a kashrut question about a marked product can arrive as long as the product exists.
• Verification lookups: at least two years, because the fraud signal they exist to carry (clause 17.10) is a pattern over time.
• Access tokens: until expiry or revocation; they are hashed and evidentially worthless beyond that.

22.2.2 Whether the system enforces this is answered plainly: it enforces the floor and nothing else. The database's refusal to delete (clause 22.1.2) makes early destruction of the evidence classes impossible, which is the enforcement that matters for a permanent-retention policy. But no code anywhere measures the age of a record, no retention period is stored in the system, and no scheduled job disposes of anything: retention as scheduled disposal does not exist in the software. For the permanent classes nothing is missing. For the classes with finite periods, disposal — if it is ever performed — is a manual, change-controlled act, and nothing would prevent a premature one on the tables whose deletes are not revoked. This is recorded as a gap, mitigated by the fact that the system's design errs only ever toward keeping.

22.2.3 The records are backed up nightly — database dump and certificate files together — with a fourteen-day rotation on the host and a copy to off-site storage, and a weekly restore drill that restores the dump into a scratch database, verifies that the triggers and constraints of clause 22.1.2 survived, and re-hashes every backed-up document against the restored manifest. A backup that has not been proven restorable is not a record, and the drill's log line — verified, missing zero, corrupted zero — is the proof.

22.3 Confidentiality and access to records

22.3.1 Records are kept confidential, and are transported, transmitted and transferred in a way that maintains confidentiality (ISO/IEC 17065:2012, 7.12.2, applying 4.5). Section 8 governs what is confidential; this clause governs how the records themselves are protected. Access to the record store is by role: the staff screens require an authenticated staff session, held in the database rather than in a self-contained cookie so that deactivating a user or changing a role takes effect on the next request; a client's portal reaches only that client's own file, and one portal address belongs to one company permanently, so a link can never open the wrong file; complaint and appeal files, visit records, findings, ingredient schedules and fees are reachable from no public route (clause 8.1.2). Credentials are stored only as hashes, and messages carrying one-time links store no body.

22.3.2 In transit, all access is over encrypted connections. Not yet implemented: the off-site backup copy is the one transfer whose confidentiality the scheme cannot presently evidence — the operational documentation records that the nightly backup is copied to a third-party store, and does not record that the copy is encrypted before it leaves. Until encryption of the off-site copy is documented and verified, clause 7.12.2 is not fully demonstrated for that path, and this is recorded as a gap.

22.3.3 Information about a client obtained from a person other than the client — a complainant above all — is treated as confidential, and the source is protected (ISO/IEC 17065:2012, 4.5.3; clause 8.1.3). Nothing a complainant submits is published, and the outcome notice tells them so in terms.

22.4 Complaints

22.4.1 A complaint is an expression of dissatisfaction with anything Emet does, or with any product carrying the Emet mark — and it may come from anyone at all: a consumer, a buyer, a rabbinic authority, a competitor, a holder. Emet operates a documented process to receive, evaluate and decide complaints, and records and tracks each one to its conclusion (ISO/IEC 17065:2012, 7.13.1). Complaints about the certification body are addressed to the certification body in the first instance (ISO/IEC 17067:2013, 6.5.5); because Emet is both scheme owner and certification body (section 2), the same process serves both.

22.4.2 The channel. The complaints procedure is published on Emet's public site as required by ISO/IEC 17065:2012, 4.6 d) (clause 8.5.1), together with a public submission form that takes the kind of case, the certificate number where one exists, a subject and the account of what happened. Name and email are optional: anonymous complaint is possible by design, because a mashgiach, an employee of a holder, or a competitor may have good reason not to be named. A quoted certificate number is tied to the certification record automatically when Emet actually issued it. Every submission mints a public reference of the form EMET-CMP-YYYY-NNNN, shown to the submitter on the spot, and writes an opening event to the audit trail. A parallel channel exists for suspect documents: the report form on the verification pages records the number tried and the account given, and unhandled reports are raised to staff by the nightly review.

22.4.3 Acknowledgement and scope. Receipt of a formal complaint is acknowledged (ISO/IEC 17065:2012, 7.13.3): the acknowledgement is a recorded staff act with its timestamp and its own audit event, and where the complainant gave an address, a written acknowledgement goes out quoting the reference and stating that the matter will be decided by someone with no interest in the outcome. On receipt Emet confirms whether the complaint relates to certification activities for which it is responsible (7.13.2); the confirmation is a recorded field on the case, and a complainant whose matter is found to be outside Emet's responsibility is told so — and is told what was found in any case. An anonymous complaint without an address is investigated identically but can be acknowledged and answered only through the record itself.

22.4.4 Investigation. Emet gathers and verifies the information needed to progress the complaint to a decision (7.13.4) — the file, the register, the visit record, the ingredient schedule, and where necessary the plant, using the access rights the certification agreement secures for complaint investigation (clause 18.3). Where the substance of a complaint is a question of kashrut — whether a product, an ingredient or a process is in fact kosher — the determination on that substance belongs to the Rav HaMachshir, and the case record holds the facts gathered for that determination and the outcome, never a ruling of the office's own. Not yet implemented: the investigation itself is thinner in the record than in the doing. The case record carries an investigating status that no code path ever sets — a case moves from received through acknowledged directly to resolved; a complainant cannot attach evidence, so a photograph of a suspect label arrives by correspondence and lives outside the case; the actions undertaken between acknowledgement and decision, which 7.13.1 requires to be recorded, have no field of their own; and the nightly review, which raises unhandled document reports, does not raise unacknowledged cases, so a complaint nobody has opened is flagged by no one. Each of these is recorded as a gap.

22.4.5 Outcome. The decision on the case is taken under the independence rule of clause 22.5.3, its outcome must be written — the software refuses a decision without one, and the database refuses a resolved case that does not name its decider, its moment and its outcome — and the complainant is given formal notice of the outcome and the end of the process wherever possible (7.13.7): a written notice quoting the reference, stating what was decided, stating where the matter was outside Emet's responsibility, and stating the route of appeal. The notice itself is recorded, with the moment it was sent, because a decision the complainant never hears is a complaint Emet closed on itself. Emet then takes whatever subsequent action the complaint requires (7.13.9): a substantiated complaint against a certified product is grounds for action under section 21, up to suspension or withdrawal, and where the kosher status of marked product in the market is affected, the holder's recall and correction obligations apply (clause 21.6; Codex CXC 1-1969, section 13.5).

22.4.6 The holder's own complaints. Under the certification agreement (§7) every holder keeps a record of complaints made known to it touching the kosher status of a certified product, acts on each, documents what was done, produces the record on request, and reports without delay any complaint suggesting a certified product failed the requirements. Review of that record is part of surveillance, which is the scheme's answer to ISO/IEC 17067:2013, 6.5.1 t); like the rest of the visit's content, its examination is not yet a structured record (clause 18.4).

22.5 Appeals

22.5.1 An appeal is a request by the party a decision was made about to reconsider that decision: a refusal to certify, a condition imposed, a reduction of scope, a suspension, a withdrawal, or a refusal to maintain the agreement. Only that party may appeal — anyone else's dissatisfaction is a complaint — and the appeal is free of charge, and never counts against the appellant in any later decision (certification agreement §16). Filing an appeal does not of itself stay the decision appealed: the register shows the current status throughout, because the register must never say something Emet has not yet decided is true.

22.5.2 An appeal is lodged through the same public channel within thirty days of the written notice of the decision, and must carry the appellant's identity and an address for the mandatory formal notice of outcome (ISO/IEC 17065:2012, 7.13.8 — which, unlike the notice to a complainant, admits no "whenever possible"). Not yet implemented: neither rule is enforced. The form accepts an appeal without a name or address, and nothing records or measures the interval between the decision's notice and the appeal, so the thirty-day window exists only in this text and standing is confirmed manually by the office before the case is progressed. Both are recorded as gaps.

22.5.3 Independence of the decision. The decision resolving a complaint or appeal is made by persons not involved in the certification activities it concerns (ISO/IEC 17065:2012, 7.13.5), and the rule is enforced in software, not only promised: before a case can be decided, the system checks the deciding user against the record of the certificate concerned — anyone who made a recorded certification decision on it is refused, and for an appeal the bar is higher: anyone who so much as drafted on the file is refused. The screen states the refusal in advance and in plain words — "you decided this, someone else has to resolve it" — because that a given person cannot decide is exactly what the appellant is entitled to know. The database independently refuses a resolved case that does not name its decider. The agreement (§16) additionally promises that no one who has advised or been employed by the client within the previous two years touches the resolution (7.13.6); section 7 of this scheme forbids Emet's personnel to consult for clients at all, which is the stronger rule, but the system holds no consultancy history and so cannot compute the two-year check — it binds as a declaration each decider makes, and this is recorded as a gap.

22.5.4 The honest limits of that enforcement. Three are stated plainly. First, the involvement check reads the decisions table — and no production code path yet writes to it (clause 20.5), so its first limb tests an empty record today; the only limb that presently bites is the drafter check. The person the check exists to catch is identifiable from the issue snapshot and the audit trail, and the office applies the rule from those by hand until the decision record is fed. Second, a case tied to no certificate blocks no one: for a case about conduct rather than a certification, independence is applied by judgement, not computed. Third, and most fundamentally: kashrut decisions belong to the Rav HaMachshir, and Emet has one Rav HaMachshir. Where the substance appealed is halachic — whether an ingredient, a process or a product is kosher — there is no second, uninvolved rabbinic authority inside this body to re-decide it, and an office decider cannot overturn a halachic determination, so clause 7.13.5 cannot be satisfied internally for that class of appeal. The system reflects this honestly rather than papering over it: the rabbinic role has no access to the case screens at all, so no case is ever resolved under the name of the authority whose determination it questions. What the office can decide independently — and does — is everything else about the decision: whether the scheme's process was followed, whether the facts the determination rested on were correct and complete, and whether the sanction was proportionate under clause 21.1. Where an appeal on the facts succeeds, the corrected facts are put back to the Rav HaMachshir for a fresh determination, which is the only body of relief a certification scheme can honestly offer against a rabbinic ruling. Referral of the halachic substance itself to an independent rabbinic authority is a course open to the Rav HaMachshir in any case he sees fit; the scheme records that no standing arrangement for such referral yet exists, and states the consequence plainly rather than implying a review tier it does not have. There is likewise no external body above this scheme to which an unresolved appeal lies: Emet is its own scheme owner (ISO/IEC 17067:2013, 6.5.5, applied to a body that is both), and an appellant's remaining recourse after the appeal process completes is at law, as the agreement's liability and jurisdiction provisions state.

22.5.5 The appellant is given formal notice of the outcome and of the end of the appeal process (7.13.8): the notice states what was decided, and states that the decision was made by persons who took no part in the decision appealed. The notice and its moment are recorded on the case.

22.6 Records of complaints and appeals, and their use in improvement

22.6.1 Every complaint and appeal is a permanent record (ISO/IEC 17065:2012, 7.13.1): the case row cannot be deleted or truncated by the running application, the reference is minted at submission and never reissued, the opening and the decision each write an event to the append-only audit trail, and the database refuses a resolved case lacking its decider, its moment or its outcome. The record holds who raised it (or that it was anonymous), what was alleged, the certificate concerned, whether the matter was within Emet's responsibility, when it was acknowledged, who decided it, what was decided, and when the person who raised it was told. Not yet implemented: the record of the actions undertaken between acknowledgement and decision — the investigation itself — has no structure (clause 22.4.4), so the case file demonstrates its endpoints better than its middle; and unlike the audit trail, the case row's own columns are not write-protected at the database (clause 22.1.2). Both are recorded as gaps.

22.6.2 The case record exists to be learned from, not only kept. The scheme requires the record of complaints and appeals to be reviewed periodically as a whole — for repeat subjects, repeat holders, repeat failure modes, and any pattern suggesting a weakness in evaluation, surveillance or decision — with the findings feeding corrective and preventive action, up to and including changes to this scheme document, and the review is an input to Emet's management review of the system. A complaint substantiated against a certified product feeds directly into that facility's risk standing for surveillance intensity (clause 18.2). Not yet implemented: no screen aggregates or trends the case record — the staff view is a working list of individual cases — and the periodic review is a manual procedure performed outside the system, on the record the system keeps. Making the pattern visible is recorded as a gap; keeping the record that makes the review possible is not, and is done.

Part V — The mark and its use

23 The Emet mark

23.1 Nature and ownership

23.1.1 The Emet mark is a certification mark, the property of Emet Kosher Certification. Its presence on a product is an attestation, made by Emet and not by the producer, that the product is a certified product of the scheme and holds the kosher status the mark's designation states. The mark is never sold, assigned or transferred; it is licensed under section 24.

23.1.2 Emet exercises the control over ownership, use and display of the mark, the licence and the certificate that ISO/IEC 17065:2012, 4.1.3.1 requires of a certification body, as specified in this Part. This Part is drafted with regard to ISO/IEC 17030 on third-party marks of conformity (noted at ISO/IEC 17065:2012, 4.1.3.1, Note 2, and again at 4.1.2.2 i), Note) and to ISO/IEC 17067:2013, 6.5.6 on licensing and control of the mark.

23.1.3 The mark attests one product line at a time. It asserts nothing about the producer as a company, about other products of the same producer, about a facility as such, or about any product not on the schedule of the certificate under which it is applied.

23.2 Form

23.2.1 The mark is a scalloped seal of sixteen scallops enclosing the letter aleph, with the designation, where one applies, set to the right of the seal as part of the same artwork. The scallop count is fixed as part of the mark's specification and is not a design variable. The seal is drawn intact: no variant of the mark breaks the ring, because a breached seal signifies tampering — the one meaning this mark must never carry.

23.2.2 The mark is to be distinguished from the status seal used on Emet's own screens, which is a plain ring in a status colour and which deliberately dashes for a suspended certificate and cleaves for a withdrawn one. That device is a register indicator, never a mark of conformity, and is never supplied to a holder in any format.

23.2.3 The canonical mark is a single colour at full strength, black (K100). No tint, screen, gradient or multi-colour build of the mark exists. A version for dark backgrounds is drawn separately, with heavier strokes, rather than by inverting the positive artwork.

Gap, stated: the prepress specification issued with every pack tells the printer that the reverse artwork knocks out, but the generator does not produce a knockout. Every reverse output — vector, SVG and PNG alike — paints a solid dark panel behind the white artwork. Until the generator emits a true knockout, the reverse files must not be described to a printer as knockout artwork, and the specification sheet overstates what is in the pack.

23.2.4 The mark exists in two cuts: the full cut, for reproduction at 11 mm diameter and above, and a compact cut stroke-tuned for 8 mm, which omits the inner hairline. Neither cut carries micro-type, and neither may be reproduced below its minimum size. The minimum sizes are stated in the usage guide and in the prepress specification; nothing downstream of Emet can enforce them, and they bind as terms of the licence.

23.2.5 All artwork is generated by Emet from a single source (src/server/artwork/mark.ts), which produces every output format from one geometry so that the vector, print and raster files agree. Every generated file carries an artwork identifier stating the variant, polarity, cut and version (for example EMETD_POS_FULL_v1), stamped into the filename, so that an approval under 24.5 names an exact file. The identifier is additionally written into the file metadata of the vector master; the SVG and PNG outputs carry it in the filename only.

23.3 Variants and what each asserts

23.3.1 The mark has seven variants. The designation is part of the mark, delivered as one outlined vector; a licensee never receives a bare seal with instructions to add a letter, and may never add, remove, substitute or separately typeset a designation (agreement clause 10.3).

23.3.2 What each variant asserts:

• (a) Plain seal (no designation) — the product is pareve: it contains neither dairy nor meat, was not made on dairy equipment, contains no fish, and the mark makes no Passover claim. Applied to a product, the plain mark is a positive claim and not a neutral logo; for this reason the artwork generator has no default variant and refuses to emit a mark without an explicit variant instruction. The seal also serves as Emet's own masthead on its certification documents, where it identifies the body and asserts nothing about any product.
• (b) PAREVE — pareve, stated in words.
• (c) D — dairy: the product contains dairy ingredients.
• (d) DE — dairy equipment: pareve ingredients, produced on dairy equipment that was not kosherized. The scheme distinguishes DE from D; a milk-free product does not carry a dairy designation.
• (e) Meat (spelled out, never a bare "M") — meat, including poultry.
• (f) Fish — the product contains fish, which is restricted with meat.
• (g) P — kosher for Passover. P means Passover and never pareve. A pareve product carries the plain seal; a P designates a product certified under a Passover-scheme certificate and nothing else.

23.3.3 Qualifier statements — Cholov Yisroel, Pas Yisroel, Yoshon, Glatt, kitniyot warnings — are words and never single letters, and where they are carried on a pack they must be locked to the seal as supplied artwork. Gap, stated: no qualifier lockup exists in the artwork generator. These qualifiers are presently carried only on the certificate schedule and in the public register entry, as recorded designations. Until the lockups are drawn and derived, no qualifier may be represented to a holder as available artwork, and none may be set by a licensee alongside the mark.

23.3.4 The kosher status a variant asserts is a rabbinic determination. Passover fitness and the conditions printed on every certificate are decided under the authority of the Rav HaMachshir through the conditions process of Part III, which records the decision, the day it was given, whose it was and how it reached the office. The classification of each product (pareve, dairy, meat) and its designations (dairy equipment and the like) are recorded on the certificate by Emet's staff under Part II; the system does not hold a separate rabbinic approval record for a classification as it does for the conditions, and the authority for the classification rests on the Part II process rather than on anything the software attests.

23.3.5 The artwork system makes no kashrut judgement: it derives the variant mechanically from the recorded classification (variantForProduct): a product on a Passover-scheme certificate carries P; a dairy product carries D; a meat product carries Meat; a pareve product with the dairy-equipment designation carries DE; any other pareve product carries the plain seal. It is therefore impossible for the generator to emit a pareve seal for a product whose recorded classification is dairy.

23.3.6 Gaps, stated:

• (a) The explicit-PAREVE and Fish lockups are specified and drawable, but no derivation rule maps a certified product line to them; the fish designation is not wired to the generator. Until it is, a fish-containing product must not be certified into a variant that conceals that fact.
• (b) The Passover variant does not stack with a base designation. The derivation returns P before it tests classification, so every product on a Passover certificate — dairy, meat and pareve alike — is authorised the same bare P lockup, and the dairy or meat fact disappears from the mark. This contradicts 24.4.2, which requires the designation to be the one derived from the product's recorded classification. Until a combined lockup exists and is derived, a dairy or meat product must not be certified under the Passover scheme in a way that would put an undesignated P mark on its pack, and any such artwork is decided by written correspondence outside the system.

23.4 The mark and the certificate

23.4.1 Every certificate derives, from the current schedule rows of that certificate, the exact set of lockups its products authorise (authorisedLockups), grouped by variant with the certified product lines each variant covers. That set is the whole of the holder's entitlement; no variant outside it exists for that holder. Because the set is computed from the live schedule and never frozen, a change to the schedule narrows or widens the entitlement from the moment it is recorded.

23.4.2 Every certificate states, in its printed conditions, whether the certification travels with the product as listed or only with product bearing the mark (the mark-dependence condition of Part III). Where a product line is certified only when bearing the mark, its schedule entry and its public register entry both state "symbol required". The mark, the certificate and the register are therefore three statements of one fact, and the register controls: the certificate itself provides that it is valid only while the register shows it active (agreement clause 9.3).

24 The licence

24.1 Basis of the licence

24.1.1 The right to use the mark is a licence, granted only through the certification agreement (section 10 of the agreement; 18 sections, 81 clauses, version-controlled), satisfying ISO/IEC 17065:2012, 4.1.2.2 i) — with e), f), g) and h) — and ISO/IEC 17067:2013, 6.5.6. The mark usage guide issued with the certificate forms part of the agreement (agreement clauses 1.4 and 10.5); its rules on size, colour, clear space and reproduction bind as the agreement does.

24.1.2 No certificate is issued unless the current version of the agreement stands accepted. The system enforces this at issuance: acceptance records who accepted, when, from which address and which version; the clause text is frozen onto the certificate at sending, so that what was accepted can always be re-read rather than re-rendered from today's wording; and issuance refuses both when no acceptance stands and when the accepted version is not the current one.

Gap, stated: the agreement also provides that a suspended certification is not restored unless the current version stands accepted (agreement clause 1.3). The system does not enforce that half: reinstatement is a status transition requiring a reason, and it performs no agreement check. Until it does, the acceptance is verified by staff before a reinstatement is recorded.

24.1.3 The licence is non-exclusive, non-transferable, revocable and not sublicensable. Co-packers, repackers and private-label customers each require their own written authorisation from Emet; a licensee cannot pass the mark on (agreement clause 10.1).

24.1.4 The licence rests on three continuing facts, and lapses with any of them:

• (a) a valid certificate — the mark is usable only on the products, brands and facilities on the current schedule, and only while the certificate is valid (agreement clause 10.2), which the certificate itself defines as while the register shows it active (agreement clause 9.3);
• (b) surveillance — the right to use the mark rests on surveillance of ongoing production (agreement clause 8.2; ISO/IEC 17065:2012, 7.9.3). Where surveillance cannot be completed for reasons on the holder's side, the basis of the licence lapses and the certification may be suspended. Gap, stated: the system records supervision visits, their findings and whether a visit was unannounced, but holds no next-visit date and no surveillance interval, and the nightly sweep flags overdue corrective actions while flagging no overdue visit. The lapse in this clause is applied by staff decision under Part IV, not computed;
• (c) supplied artwork — reproduction is permitted only from artwork Emet supplies, unaltered in any way: no redrawing, recolouring, screening, distortion, rotation, effects or additions (agreement clause 10.2).

24.2 Delivery of artwork

24.2.1 Artwork is delivered only as the certificate pack, generated per certificate and containing exactly the lockups that certificate authorises and nothing else. The restriction is the control: a variant the certificate does not authorise is never delivered in any format. No other path in the application emits an artwork file.

24.2.2 The pack is available only through the authenticated client portal, only to the holder company of the certificate, and only while the certificate is active. The download route loads the certificate row, requires its holder to match the session's company, and refuses any certificate whose recorded status is not active — so that suspension and withdrawal stop delivery immediately.

Gap, stated: expiry does not stop delivery. Expiry is derived when a record is read and is never written to the certificate row, so a certificate that has lapsed still reads as active to the download route. The portal hides the download link, because the page derives the status correctly, but the route remains reachable by its address. Until the route is gated on the derived status, expiry stops the licence without stopping the delivery, and this is recorded as an open defect against ISO/IEC 17065:2012, 4.1.3.1.

24.2.3 The pack contains: the certificate; per authorised variant, print artwork (vector, outlined, K100, positive and reverse, full and compact cuts) and digital artwork (SVG and transparent PNG); the usage guide; and a prepress specification. The following are never supplied: JPEG artwork, layered files, live type or fonts, any decorative variant of the seal (document and website use only), any variant not on the certificate, or a bare seal without its designation.

24.2.4 The scheme requires that every artwork delivery be logged — which file, to whom, when — as evidence in any later dispute over how a mark reached a package. Gap, stated: neither the client route nor the staff route writes such a record, and no audit event is raised on a download. The requirement stands against the body and is not implemented.

24.3 Application to packaging

24.3.1 Placement: the mark is applied on the principal display panel, adjacent to the product name, consistently across a product range. It is never placed on a bottom panel, glue flap, seam or gusset; never split across a fold; and never positioned where it could be read as certifying a different product on the same package, a neighbouring product, or a single ingredient rather than the product. These rules are stated in the usage guide issued with every certificate.

24.3.2 Reproduction: minimum 11 mm (full cut) or 8 mm (compact cut) diameter; clear space of half the seal's diameter on all sides, free of type, graphics and trim; one ink at full strength — black, or the darkest single line colour with Emet's prior written approval; on dark backgrounds, only the supplied reverse artwork.

24.3.3 The mark supplements and never substitutes for lawful labelling. Product information and labelling remain the producer's obligation under Codex CXC 1-1969, sections 14.2 and 14.3, the latter applying CXS 1-1985; and lot identification sufficient to enable recall of marked product remains required under CXC 1-1969, section 14.1, which likewise applies CXS 1-1985.

24.4 The bar on uncertified and over-broad use

24.4.1 The mark shall never appear on a product that is not a certified product of a current certificate. This includes line extensions, seasonal variants, size or flavour variants and reformulations of a certified product: a product line with no entry on the schedule has no mark, and a mark is never moved between products.

24.4.2 The mark and every reference to certification shall never imply a certification wider than granted: not that an uncertified product, brand or facility is covered, not that a Passover certification exists where none does, not that certification of a product certifies its producer, and not any designation other than the one derived from the product's current recorded classification (agreement sections 10 and 11). The Passover derivation does not presently satisfy the last of these; see 23.3.6 (b).

24.4.3 Any change to ingredients, suppliers, formulation, processing aids, shared equipment or place of manufacture requires Emet's approval before implementation; approval is never retrospective, and use of the mark on product made after an unapproved change is unauthorised use (agreement clauses 6.1–6.3).

24.5 Artwork approval

24.5.1 No packaging, label, advertisement or web page bearing the mark may be printed or published until Emet has approved the final artwork in writing (agreement clause 10.4). Approval is per exact artwork file and per brand, not per client.

24.5.2 The approval record (LabelArtwork) binds together the certified product line, the brand name as it stood at approval (held as its own field, so a later renaming cannot orphan the record), the mark variant, the artwork identifier of 23.2.5, the attached artwork file, and the identity and date of the approver. The decision path enforces, before any approval: that the certificate is active; that the variant is within the certificate's authorised lockup set of 23.4.1 — an unauthorised variant cannot be approved at all; and that the artwork file is attached, so no approval exists without the thing approved. The decision is a compare-and-set on the submitted state, so a decided artwork cannot be decided again. The review screen additionally shows an advisory warning where the variant does not match the product's classification; that warning is not a gate, and it presently misfires on Passover artwork, which the lockup gate correctly allows.

24.5.3 Gaps, stated plainly:

• (a) The intake by which artwork enters the system — the holder's submission and the file upload the approval requires — is not implemented; no path in the application creates an artwork record or attaches a file. Until intake exists, the duty in 24.5.1 is discharged by written correspondence outside the system, the decision gates of 24.5.2 cannot operate on anything, and this is recorded as an open gap against ISO/IEC 17065:2012, 4.1.3.1, to be closed before any approval is represented as system-controlled.
• (b) The scheme requires that a replacement approval supersede its predecessor rather than replace it, and that a reformulation invalidate an approval rather than delete it. The record can hold both outcomes — the superseded and invalidated states exist as recorded values — but nothing writes either: no path supersedes an approval, and no change to a product invalidates one. Both are requirements not yet wired to the change process.

25 Misuse, and marked stock on suspension or withdrawal

25.1 What constitutes misuse

25.1.1 Misuse is any incorrect reference to the scheme or misleading use of the licence, the certificate or the mark, within the meaning of ISO/IEC 17065:2012, 4.1.3.2, including: the mark on an uncertified product, brand or facility; a designation that does not match the product's current certified status; altered, redrawn or separately typeset artwork; use below minimum size or outside the colour and placement rules; use after suspension, withdrawal, expiry or scope reduction; use on product made after an unapproved change (24.4.3); Passover artwork applied to production of a later season; sublicensed or passed-on use by a co-packer, repacker or distributor without its own authorisation; and any claim of certification in documents, advertising or online that is misleading or exceeds the scope granted.

25.1.2 A claim of Emet certification by a party holding no certificate is not a licence matter but a fraudulent claim (ISO/IEC 17067:2013, 6.5.12), and is dealt with under 25.2.4.

25.2 What the body does

25.2.1 On substantiated misuse by a certificate holder, Emet acts under the graduated response the holder has already accepted (agreement clauses 10.6 and 13.1; ISO/IEC 17065:2012, 7.11.1, whose Note sets out the same four responses, and 4.1.3.2, whose Note contemplates corrective action, withdrawal, publication and legal action): a written demand for correction within a stated period; continuation under stated conditions such as increased surveillance; reduction of scope to remove the affected products; suspension pending corrective action; or withdrawal. Every adverse decision is made in writing with reasons, requires a recorded reason and a reason category in the system, and — for suspension — a written restoration plan stating exactly what ends the suspension, which the system refuses to record a suspension without (ISO/IEC 17065:2012, 7.11.4).

25.2.2 Emet may publish a corrective notice identifying the product and its actual status. The holder has consented in advance that such publication is not a breach of confidentiality (agreement clauses 10.6 and 12.5). Gap, stated: the system has no corrective-notice publication path. What it publishes on a status change is the register entry described in 25.2.3; a corrective notice beyond that is issued outside the system.

25.2.3 The public register is the standing control against misuse. Every status change updates the register immediately, because the register reads the live record rather than a copy (ISO/IEC 17065:2012, 7.11.3; agreement clause 13.7): a suspended certificate shows as suspended with its restoration plan and the written reason, a withdrawn one as withdrawn with its written reason, and a certificate withdrawn because it was issued in error is published as voided and worded distinctly from an ordinary withdrawal. Emet confirms to anyone who asks whether a certificate is valid (agreement clause 12.3). Verification is free, unauthenticated and answerable by the QR code carried on the certificate and its schedule; every lookup is recorded with its outcome; and a number that was never issued is answered as such, distinctly from a number that was mistyped.

25.2.4 Against a non-holder, Emet enforces the mark as its trademark: demand, injunctive relief, and publication of the fraudulent claim. Stated: no trademark registration for the mark is recorded in the system or its documentation, and the enforcement in this clause depends on Emet's rights in the mark being established; that record must be held outside the system and produced when the clause is relied on. Any person may put a suspected misuse to Emet through the public complaints channel, which accepts submissions without a name or an address and links a quoted certificate number automatically where Emet issued that number; complaints alleging that a marked product is not kosher are handled under the complaints process of Part VI by persons uninvolved in the certification decision concerned.

25.3 Suspension

25.3.1 On suspension the holder stops applying the mark to the suspended products at once and stops all advertising that refers to their certification (agreement clause 13.2). The pack ceases to be downloadable the moment the status changes (24.2.2).

25.3.2 Product lawfully marked before the suspension may continue to be sold unless the suspension notice states otherwise. A suspension not resolved within its stated period becomes reduction or withdrawal.

25.4 Withdrawal, termination and expiry

25.4.1 On withdrawal, on termination at the holder's request, and from the effective end date on expiry without renewal: all rights in the mark end immediately; the holder returns the certificate, stops applying the mark and stops all certification advertising at once; and within 30 days destroys or surrenders unused packaging, labels and films bearing the mark, certifying this to Emet in writing (agreement clauses 13.3 and 13.5). Nothing produced after the end date may carry the mark. On expiry, the end of the rights is not presently matched by an end of artwork delivery; see 24.2.2.

25.4.2 Finished product lawfully marked while the certificate was valid may sell through normal channels — unless Emet determines that its kosher status is affected, in which case the holder cooperates fully with corrective action, including recall, over-labelling or public notice, at the holder's cost (agreement clause 13.3; ISO/IEC 17067:2013, 6.5.8; recall procedures per Codex CXC 1-1969, section 13.5, supported by the lot identification of 24.3.3).

25.4.3 Gap, stated: the system flips the register, blocks the pack on suspension and withdrawal, and records the status decision with its reason and reason category; it holds no stock-disposition record tracking the 30-day destruction certificate of 25.4.1. Receipt of that certification is filed as correspondence, and the structured record is not implemented.

25.5 Reduction of scope, and Passover lapse

25.5.1 On reduction, Emet issues a corrected certificate and schedule, and the holder brings every claim, label and use of the mark within the reduced scope at once; for the products removed, the obligations of 25.4 apply as if their certification had been withdrawn (agreement clause 13.4). Because the authorised lockup set of 23.4.1 is derived from the schedule rather than stored, a reduction narrows it as soon as the schedule changes, and the next pack contains only the narrowed set.

Gap, stated: the scheme requires that every artwork approval for a removed product cease to stand. Nothing in the system marks those approvals; a reduction leaves them recorded as approved. Until 24.5.3 (b) is implemented, the approvals affected by a reduction are identified and withdrawn by correspondence.

25.5.2 The P variant dies with its season. Passover certification is issued per season — the validity window is computed from the Hebrew calendar and ends on the last day of the festival, never twelve months from issue — and P artwork applied to production of any later season is misuse under 25.1.1, because it asserts supervision of a Passover nobody supervised. Gap, stated: season validity is a rule of the scheme; the generated artwork carries no season stamp, the artwork identifier encodes only variant, polarity, cut and version, and nothing expires Passover artwork or its approval. Enforcement rests on the certificate's own validity dates and on surveillance.

Part VI — Annexes

VI.0 Status of these annexes

VI.0.1 These annexes are operative parts of the scheme. Where an annex and the body of the scheme differ, the body prevails; where an annex states a system behaviour, the behaviour described is that of the certification system as built and running.

VI.0.2 Each requirement in these annexes carries one of two markers. [Operating] — the requirement is implemented in the certification system and the description states what the system does. [Requirement — not yet implemented] — the scheme places the requirement on the body, but no system function yet performs it; until it is implemented the body discharges it by the manual means stated, and the gap is an input to the scheme review under Annex E. Nothing in these annexes describes as operating a control that does not operate. A control that exists in the database but that no workflow can reach is described as such, and is not an operating control.

VI.0.3 Every ruling on what is kosher — what a classification or designation means in halacha, whether an ingredient is acceptable, whether a kashering is valid, what may be certified for Passover — belongs to the Rav HaMachshir and to no one else. These annexes define the process by which such rulings are requested, recorded, applied and published. They do not contain the rulings (ISO/IEC 17065, 7.1.3: explanations of the application of the requirements are formulated by relevant and impartial persons possessing the necessary technical competence).

VI.0.4 Citations in the form (ISO/IEC 17065, n.n), (ISO/IEC 17067, n.n) and (CXC 1-1969, §n) identify the clause of the referenced document to which the requirement traces. This scheme is written to align with ISO/IEC 17065:2012 and ISO/IEC 17067:2013. No assessment of conformity to either has been performed by any party, and nothing in this scheme asserts otherwise.

Annex A — Classification and designation

A.1 Purpose and rule of decision

A.1.1 This annex defines every classification, designation and mark variant the scheme recognises, what each asserts, and the conditions under which each may be applied to a certified product (ISO/IEC 17067, 6.5.1 i — the statement of conformity must unambiguously identify the product to which it applies; 6.5.1 j — the conditions under which the client may use the statement of conformity or marks of conformity).

A.1.2 The assignment of a classification or designation to a product is a certification decision. The halachic content of that decision belongs to the Rav HaMachshir (VI.0.3). The system's role is to record the decision, refuse combinations that cannot be true, and print exactly what was decided.

A.1.3 [Operating] No classification is ever assumed. At application acceptance, the reviewer must state a classification for every product individually; there is no default, and acceptance throws — creating nothing — for any product left unclassified. The system refuses the default deliberately: an unmarked kosher symbol is itself a positive pareve claim, so a defaulted classification would silently declare a product free of dairy and meat.

A.2 Classifications

A.2.1 The three classifications are mutually exclusive. Every certified product carries exactly one. Everything else a product can be — Cholov Yisroel, Yoshon, Glatt — is a designation (A.4), never a fourth classification.

A.2.2 Classification attaches to the product as produced, not to the recipe. The draft normative document EKS-02 defines classification against the production line (Annex D, D.3); until EKS-02 is in force, the operative definition in each case is the Rav HaMachshir's ruling, recorded against the certificate.

A.2.3 [Operating] Every certificate carries four condition statements — what the mark means, Passover fitness, the cholov standard, and what the sheet alone proves — held as four separate fields and printed as two lines, composed by a fixed pairing that the author of the words does not control: the mark statement with the Passover statement, then the cholov standard with the proof caveat. The four fields are not one free-text box because silence on any one of them is read as a claim — dairy with no cholov standard stated is taken by the stricter consumer as one they may eat.

[Operating] The refusals that keep a slot from being empty sit at three points, and none of them is issuance: the wording cannot be proposed with any slot shorter than eight characters, longer than ninety, or carrying a control character; a draft cannot be built for a scheme that has no approved condition set in force, and drafting throws rather than printing a blank; and the renderer refuses a snapshot that carries no condition lines. The condition wording itself is controlled under Annex E, E.3.

A.2.4 [Operating] A product's classification may be corrected after acceptance. The change is a deliberate two-step act in which the meaning of each classification is displayed before confirmation, and it carries the consequences with it: a designation that was true of the old status and is not true of the new one is deleted in the same transaction, so a reclassification cannot strand "Cholov Yisroel" on something that has just stopped being dairy. A classification change on an issued certificate takes public effect only through a client-approved revision and reissue; the superseded document remains detectable through its integrity code, which answers SUPERSEDED, naming both the revision in the reader's hand and the current one.

A.3 Dairy-equipment status

A.3.1 "Pareve — dairy equipment" is not a fourth classification. Halachically the product is pareve, with a caveat about the line it was made on. [Operating] The system stores it as classification PAREVE carrying the designation DAIRY_EQUIPMENT, and both the certificate and the mark generator understand the combination: such a product takes the DE mark variant, never the plain mark (A.5.2).

A.3.2 Whether a given line confers dairy-equipment status, and whether and how it may be kashered to pareve, is the Rav HaMachshir's ruling in each case. The scheme records the ruling; it does not define kashering.

A.4 Designations

A.4.1 A designation is an additional attribute a certified product may carry beyond its classification. [Operating] The system holds the designation register as reference data. Each designation declares which classifications it may sit beside, and the system enforces the constraint at application acceptance — a designation applied to an incompatible classification is refused with an error naming the designation and the product, because it would be a statement about a food that cannot be true, printed on a certificate — and enforces it a second time on reclassification, by deleting what no longer applies (A.2.4).

A.4.2 The recognised designations, their compatibility, and what each asserts:

The operative definition of each designation is the ruling of the Rav HaMachshir, to be codified in EKS-02 when it enters force (Annex D, D.3). The one-line assertions above locate the designation; they are not the ruling.

A.4.3 Availability. A designation may be granted only where the body can actually supervise it. A designation the body cannot staff must not be offered: a standard that describes Cholov Yisroel while nobody can supervise the milking is a claim the body cannot keep. Accordingly:

• [Operating] The only designation the system can attach through its own workflow today is Dairy Equipment, chosen at application acceptance as the fourth option of the classification question and stored as PAREVE + DAIRY_EQUIPMENT. No screen offers any other designation for grant.
• The remaining six designations exist in the register as reference data with no grant path in the workflow. This is deliberate. A designation other than Dairy Equipment shall not be granted until (a) EKS-02 defines its evidence requirements and is approved by the Rav HaMachshir, and (b) the supervision it requires is staffed. [Requirement — the availability gate is currently the absence of a workflow, not a recorded rule; the rule is this clause. Nothing in the system would refuse such a designation if a write path were added.]

A.4.4 [Operating] Granted designations are frozen into the certificate snapshot at issue with both their code and their print label, so that a later change to the wording of a designation cannot retroactively alter what a certificate issued today claims; and they are published on the public verification entry for the certificate.

A.5 The mark and its variants

A.5.1 The mark is a scalloped seal issued in seven variants. Each variant is a distinct assertion; the variant letter is part of the claim, not decoration (ISO/IEC 17067, 6.5.1 k — ownership, use and control of the marks; ISO/IEC 17065, 4.1.3).

A.5.2 [Operating] The variant for each product is derived, never chosen freely: a Passover-scheme certificate takes P; a DAIRY product takes D; a MEAT product takes MEAT; a PAREVE product carrying the Dairy Equipment designation takes DE; only a pareve product with no such designation takes the plain mark. The mark generator has no default variant — a caller must state one — because a generator defaulting to the plain mark would eventually put a pareve claim on a dairy product, which is simultaneously a kosher failure and an allergen recall.

A.5.3 [Operating] The mark is cut at two sizes (full, 11 mm minimum, and compact, 8 mm minimum) and a drawn — not colour-inverted — reverse. The set of lockups a certificate holder may use is derived from that certificate's own products; the client pack contains exactly those artwork files — print PDF and vector SVG and PNG in both cuts and both polarities — together with the certificate PDF, the prepress specification and the usage guide (form EMET-F-04, Annex D), and nothing else. Artwork outside the pack is not licensed artwork.

A.5.4 When the mark may be applied. Only on products listed on the schedule of a currently valid certificate; only in the variant the certificate authorises for that product; only from artwork supplied in the pack; and only after the body's written approval of the specific printed label (certification agreement, clause 10.4). Where a product's schedule entry states "certified only when bearing the symbol", an unmarked pack of that product is not certified. [Operating for the derivation of authorised variants and for pack contents.]

A.5.5 [Requirement — not yet implemented] Label-artwork approval — the record that a specific printed label was reviewed and approved before print — has no intake. An approval screen exists and its checks are real: it refuses any lockup the certificate does not authorise, refuses approval against a certificate that is not active, and the database refuses an APPROVED artwork row that carries no file. But no screen can create an artwork record, no file can be attached to one — the system has no file-upload path of any kind, and the only files it ever writes are the PDFs it generates itself — so the artwork queue is永 empty and the approval screen unreachable. Until the workflow exists, approval before print is performed outside the system, in writing, to the address the client pack states, and the correspondence retained in the client file. This is a known gap against ISO/IEC 17065, 4.1.3, and an input to Annex E.

A.6 Passover

A.6.1 Passover certification is a separate scheme, not a designation. A Passover certificate covers a defined production and expires with the festival it covers; its products carry the P variant. What may be certified for Passover — including the treatment of kitniyos — is defined by EKS-05, which is drafted and awaits the Rav HaMachshir's approval (Annex D, D.3).

A.6.2 [Operating, as a refusal] The system currently cannot produce a Passover certificate, and it is important to state where the refusal actually sits, because it is not where it might be assumed.

• Passover is offered as a choice on the public application form, and a Passover application can be submitted and accepted.
• The Passover validity window is implemented: a Passover certificate is dated from issue to the last day of Pesach (22 Nisan), computed from the Hebrew calendar and never typed.
• The refusal is at drafting. No Passover condition wording has ever been decided by the Rav HaMachshir, and only the standard scheme's wording is seeded. Building any draft resolves the conditions in force for that scheme and throws when there are none, so a Passover draft cannot be created at all. The condition-wording screen is additionally hard-wired to the standard scheme, so Passover wording cannot even be proposed through the system.
• The renderer carries an independent refusal: it will not print the standard "not certified for Passover" line under a title reading CERTIFICATE OF KOSHER SUPERVISION FOR PASSOVER.

These refusals are the control. Passover certification is not offered until EKS-05 is in force and the Passover condition wording has been proposed, previewed and activated under E.3. [Requirement — the public application form should not offer a scheme the body cannot certify; removing or gating that option is an input to Annex E.]

Annex B — Ingredient risk categories and evidence

B.1 Principle

B.1.1 [Operating] Ingredient approval is facility-scoped, never global. An approval is a decision about one ingredient, from one producer, at one producing plant, under one item code, for use at one certified facility. The same lecithin can be approved at plant A and unapproved at plant B. The system keys every approval on exactly that tuple and enforces it as a uniqueness constraint; a pair of composite foreign keys makes it physically impossible for an ingredient approved at one facility to be attached to a product certified at another. The approved list for a facility ("Schedule A") is the reference for receiving checks under Annex C.

B.1.2 Which category an ingredient falls into is a rabbinic determination made per ingredient by or under the authority of the Rav HaMachshir, recorded as a decision with a named owner. The categories below define the evidence the scheme requires once the determination is made; they do not pre-decide any ingredient (VI.0.3).

B.1.3 Schedule A is confidential. It is a client's bill of materials and is never published (ISO/IEC 17065, 4.5; certification agreement, section 12).

B.2 The categories

Category 1 — Innocuous. [Operating] Ingredients acceptable from any source as ruled by the Rav HaMachshir (typically salt, raw produce, water and the like — the list is his, not the scheme's). Evidence required: identification of the item sufficient to recognise it at receiving. The innocuous ruling is still a decision, recorded with an owner and a date — the database refuses an INNOCUOUS row that carries neither — never an absence of a decision; the system holds it as a distinct status so that "nobody looked at this" and "this needs nothing" can never be confused.

Category 2 — Certified by an accepted agency. Ingredients whose status rests on another certifier's letter. The scheme requires all of the following before approval. What the system enforces, and what it does not, is stated for each element, because at present only one of the four is a system control.

[Requirement — not yet implemented] The accepted-agencies list cannot be populated. No screen creates a certifying agency and none is seeded, so the list is empty, the agency selector on the letter form has nothing in it, and no letter of certification can be recorded through the system at all today. Until an agency register with a create path and an accept/withdraw decision exists, both the list of accepted agencies and the letters themselves are held in the client file outside the system. Input to Annex E.

Category 3 — Restricted to source. [Operating] Ingredients approved only from a named producer and plant, on the Rav HaMachshir's ruling that the item is acceptable from that source and from no other. Evidence: as Category 2, plus the restriction itself recorded in words — the system refuses a RESTRICTED_TO_SOURCE decision that does not carry the restriction, and the database refuses such a row independently. Any change of source is a change requiring prior approval under B.6; delivery from any other source is an unapproved ingredient (Annex C, item C-13.2.8).

Category 4 — Sensitive, uninvestigated or refused. Everything else: ingredients pending investigation, and ingredients the Rav HaMachshir has rejected. [Operating] Both states are recorded, and pending and rejected are distinct statuses that cannot be confused. Ingredients in this category are rejected, substituted, or investigated at source under the Rav HaMachshir's direction; a source investigation that succeeds moves the ingredient to Category 2 or 3 by a new recorded decision, made through the only path that can set a status at all.

[Requirement] That a product formulated on a pending or rejected ingredient is not an approved product is a rule of this scheme, and the database is written to enforce it — but only on a linkage that cannot currently be made (B.4.2). Until the linkage exists, this is a reviewer's judgement at approval and at every inspection.

B.3 Letters: expiry and supersession

B.3.1 [Operating] A letter is never edited in place. A renewed or corrected letter supersedes the old row in the same transaction that inserts it; a partial unique index permits exactly one live letter per approval; and the runtime database role has no DELETE right on letters at all. The evidence an approval rested on at any date therefore remains reconstructible (ISO/IEC 17065, 7.12.1).

B.3.2 [Operating] The system's nightly sweep counts letters that are live, expiring within 60 days, and attached to an approval that is APPROVED or RESTRICTED_TO_SOURCE, and reports the count to every active staff account. The facility screen additionally marks a live letter as expiring or EXPIRED against today's date.

[Requirement — not enforced] An expired letter removes the evidence under an approval; the approval must then be renewed on a current letter or the ingredient falls to Category 4. The system does not do this: an approval's status does not change when its letter expires, and nothing blocks the continued use of an ingredient whose evidence has lapsed. Acting on the sweep is the reviewer's, not the system's. Input to Annex E.

B.3.3 [Requirement — not yet implemented] The letter document itself — the PDF the agency issued — cannot be attached to the record. The system stores the letter's data, and the schema provides for the file, but there is no file intake anywhere in the application. Original letters are retained outside the system in the client file until the intake exists. Gap against ISO/IEC 17065, 7.12.1; input to Annex E.

B.4 Status-claim compatibility

B.4.1 A letter's status claim must be compatible with every certified product the ingredient is used in. A letter claiming Dairy kills a Pareve claim: a pareve product formulated on an ingredient whose evidence says dairy is misclassified, whatever the recipe says. The rule as the scheme states it is general — a claim of anything other than pareve is compatible only with a product of that same classification — and it is therefore stricter than it may look: an ingredient whose letter claims dairy equipment is incompatible with a pareve product whether or not that product itself carries the Dairy Equipment designation. That combination requires a ruling, not an assumption.

B.4.2 [Requirement — not yet implemented, in an unusual form.] The compatibility check exists and is correct. It is implemented in the database as a trigger on the ingredient-to-product linkage, and it enforces three things at once: it refuses a rejected ingredient; it refuses any non-pareve status claim against a product of a different classification, exactly as B.4.1 states; and on a live certificate it refuses any linkage whose ingredient is not approved, or that does not cite an APPROVED change request for that same facility.

None of it can ever fire, because nothing can create the linkage. No screen, action or script writes to the ingredient-to-product table; the facility screen reads it, to show an operator what an ingredient feeds before they reject it, and it is always empty. So the impact analysis the screens provide for cannot fire, and neither can the guard behind it.

Until a write path exists, the compatibility check in B.4.1 is performed by the reviewer at ingredient approval and at every inspection (Annex C, item C-13.2.8), and recorded in the visit notes; the same is true of the change-request gate in B.6. Building that write path turns three written rules into three enforced ones in a single change, which is why it ranks alongside B.6.2 as the scheme's most consequential open gap. Input to Annex E.

B.5 Who decides

B.5.1 [Operating] Every category assignment and every approval, restriction, rejection and innocuous ruling is recorded with its owner and the moment it was made — the database refuses any decided row that lacks both, and an audit event is written in the same transaction as the decision. The halachic content is the Rav HaMachshir's (VI.0.3); staff verify evidence and record decisions, they do not make rulings.

B.6 Change of ingredient, source or formula

B.6.1 No ingredient, source, supplier, formulation or processing aid of a certified product may change without the body's prior approval; approval is never retrospective, and product affected by an unapproved change is outside the certification until the body says otherwise (certification agreement, clause 6.1; ISO/IEC 17065, 7.10.2).

B.6.2 [Requirement — not yet implemented] The system defines a change-request record with the necessary kinds — ingredient addition, substitution, supplier change, formula change, new product, equipment change — and its decision path is sound: it refuses to let the requester decide their own request, the database refuses a decided request that names no decider, and the linkage guard (B.4.2) refuses to attach an ingredient to a live certificate on anything less than an APPROVED request for that facility.

But no one can raise a change request. Neither the client portal nor the staff screens have a create path; the staff screen lists requests and decides them, and the list can only ever be empty. Until an intake exists, change notifications arrive by email under agreement clause 6.1, are handled as Category 2–4 evidence work under this annex, and the correspondence is retained in the client file. Together with B.4.2 this is the scheme's most consequential open gap, because clause B.6.1 is fiction without a working intake; input to Annex E.

Annex C — Plant inspection checklist

C.1 How to use this checklist

C.1.1 This checklist structures the inspection walk. It is laid out against the sections of Codex CXC 1-1969 (General Principles of Food Hygiene, 2022 revision) because a plant walk follows the same route through a facility that the Codex document follows; the inspector covers receiving to dispatch once, recording against each row.

C.1.2 Scope of the Codex rows. Emet certifies kashrut, not food hygiene. Rows not marked [K] are the hygiene baseline of the environment the inspection moves through: the inspector observes them because a plant that cannot control cleaning, segregation or traceability cannot control kosher status either, and records material observations. They are observations, never attestations — an Emet certificate asserts nothing about conformity to CXC 1-1969. Rows marked [K] are kashrut-specific requirements of this scheme; nonconformities against them are findings under C.3.

C.1.3 The judgement rows call for — whether a changeover is adequate, whether a kashering is valid, whether shared steam is acceptable — belongs to the Rav HaMachshir. The inspector records what was seen; where a ruling is needed, the item is referred, not improvised (VI.0.3).

C.1.4 [Requirement — not yet implemented] This checklist is completed on paper or PDF and retained in the facility file. The system has no file intake of any kind — no screen accepts an upload, and the only files it holds are the PDFs it generates itself — so neither the completed checklist nor any photograph can be stored against a visit, even though the data model provides for both. The system holds the visit as a summary record only (C.3.1). Adoption of the checklist as a controlled form is pending under Annex D, D.6.

C.2 The checklist

C.3 Recording the inspection

C.3.1 [Operating] Every visit is recorded in the system with its date, the supervisor's name, whether it was unannounced, narrative notes, and the staff account that recorded it. Visits are recorded against the facility, deliberately and exclusively: every certificate at that plant shares the plant's inspection history, and a visit row carries no certificate.

C.3.2 [Operating] Each nonconformity is recorded as a finding against a visit, with a severity (minor / major / critical), a description, the required corrective action and a due date — the database refuses a corrective action with no deadline. A finding is closed only with a written closure note and a named closer, enforced at both the action and the database. An open finding at the facility blocks the issue of any renewal for that facility — the count is taken inside the issuance transaction and the issue is refused, not warned about. Overdue corrective actions are counted and reported to staff by the nightly sweep.

C.3.3 [Operating] Visit records and findings are never published, and no public route reads them. What the public register does publish, and what the certification agreement (clause 12.2) obtains the holder's consent for, is: the holder, the facility name and location unless withheld at the holder's request, the certified products with their brands, classifications and designations, the scheme, the number, the status with its dates and reasons, and the history of that status. The product schedule is therefore public — that is the point of a register — with confidential product lines suppressed entirely and confidential brand names withheld while their product stays visible, the register saying so in both cases rather than staying silent. Schedule A, visit dates, visit notes, findings and fees are not published anywhere.

C.3.4 Unannounced access is a term of certification (agreement, clauses 5.1–5.2, and 5.6 for co-packers): the holder admits the body's inspector without notice during production hours, and secures the same right at any site producing for them. [Operating as an agreement term frozen onto the certificate at the moment it was sent, and as a recorded attribute of each visit.]

C.4 Frequency and surveillance — the standing gap

C.4.1 Surveillance is required because the mark is applied to ongoing production (ISO/IEC 17065, 7.9.1, 7.9.3). The scheme is intended to operate as an ISO/IEC 17067 type 5 scheme — assessment of the product and of the production process, a licensed mark, and continuing surveillance of production, of the market, or of both (17067, 5.3.7). That intention is a scheme-owner declaration, not a system fact, and it is not yet met: the surveillance that would make it a type 5 scheme does not operate (C.4.3). Visit frequency shall be set per facility by risk category and stated in EKS-04 when it enters force.

C.4.2 The scheme's risk categories, in ascending order of supervision intensity, are: cold pareve; heated; dairy; shared line; meat. [Requirement — not implemented.] The enumeration exists in the database, but the field that holds it sits on the application, not on the facility, and no code anywhere in the system reads or writes it. It is an unused column on the wrong entity. Risk category is therefore held in the facility file outside the system, and moving it onto the facility is a prerequisite for any frequency rule.

C.4.3 [Requirement — not yet implemented] No surveillance schedule operates. The system records visits after the fact; nothing sets a frequency, computes a next-due date, flags a facility as overdue, or acts on a lapse — although the certification agreement (clause 8.2) stakes the mark licence on surveillance being completed and provides for suspension when it cannot be. The nightly sweep watches certificate expiry, overdue findings and expiring letters; it does not watch visits, and no query anywhere asks when a facility was last seen. Nor does any surveillance of the marked product in trade — sampling, market label checks — exist, as ISO/IEC 17065, 7.9.3 contemplates and as EKS-04 is drafted to require. Until EKS-04 is in force and the schedule is implemented, visit planning is performed manually by the certification office and evidenced only by the visit records themselves. These are the scheme's largest operational gaps; standing inputs to Annex E.

Annex D — Document control

D.1 The rule

D.1.1 [Operating] Every document the body issues from a template carries a control line, bottom left, of the form EMET-F-nn rev n · YYYY-MM-DD: the form's code, the revision of the form, and the date that revision came into use. The code identifies the form, never the record — two certificates issued a year apart share a document code and differ in everything else. The control line answers the one question the certificate number cannot: which version of our form is this, and is it the current one (ISO/IEC 17065, 8.3 — control of documents; ISO/IEC 17067, 6.7 addresses the scheme owner's own documentation rather than client-facing forms, and is cited here only as the scheme-level counterpart).

D.1.2 [Operating] The forms register is held in the system's code, in one place, and every document that carries a control line composes it from that register. The rule is mechanical: any change to what a template prints bumps its revision in the same change. A revision that does not move when the form moves asserts that two different documents are the same document, which is worse than no control at all. [Requirement] Nothing automated verifies that the rule was followed; it is a discipline on the change, and its observance is an Annex E review item.

D.2 The forms register

D.3 Normative documents — the EKS series

The remainder of this clause was truncated in the draft supplied for review and is reconstructed here from the body's own standards register, which is its only source.

D.3.1 The scheme's kashrut requirements are to be stated in six normative documents. ISO/IEC 17065, 7.7.1 requires a certificate to identify the normative documents the product was certified against, and 17065 does not require those documents to be ISO standards. Kosher law is not an ISO standard; these are the documents Emet's certificates are to cite.

D.3.2 [Requirement — none of EKS-01 to EKS-05 is in force.] All five are drafted and await the Rav HaMachshir's approval. No certificate may cite a document that has not been approved, and none does. EKS-06 alone is written and in issue, as EMET-F-04.

D.3.3 These documents are not published on the site, and shall not be until they are approved and the supervision they describe is staffed. Publishing requirements the body cannot yet enforce would be worse than publishing none: a standard that describes Cholov Yisroel while nobody can supervise the milking is a claim the body cannot keep (A.4.3). The order is fixed — the Rav approves, the staffing exists, and only then does the document become public and citable on a certificate. Progress against that order is a standing item of the scheme review under Annex E.

Annex E — The scheme's own review and maintenance

E.1 Ownership of the scheme

E.1.1 The owner of this scheme is Emet Kosher Certification, which is also the certification body operating it (clause 2.1, 2.2). Ownership carries the responsibilities of ISO/IEC 17067, 6.3.4 to 6.3.7: full responsibility for the objectives, content and integrity of the scheme; its maintenance; guidance on its application; and the creation, control and maintenance of its documentation (ISO/IEC 17067, 6.7). Because the requirements against which a client's products are evaluated are those of this scheme and its normative documents (ISO/IEC 17065, 7.1.2), a change to this document is a change to what every Emet certificate means, and is controlled as this annex provides — never made informally, and never made by editing the published text in place.

E.1.2 Authority to change the scheme is divided along one line and no other. Every element of the scheme that is kashrut-substantive — any requirement whose content is a matter of halacha — takes effect only with the decision of the Rav HaMachshir (clause 2.1, 2.4). Every process element is drafted against ISO/IEC 17065 and ISO/IEC 17067 with the clause traced, by persons competent in conformity assessment (ISO/IEC 17067, 6.3.8), and where explanation of the application of a requirement is needed it is formulated by relevant and impartial persons possessing the necessary technical competence (ISO/IEC 17065, 7.1.3; VI.0.3). Nobody else — no client, no member of staff acting alone, and no software change — alters what the scheme requires.

E.1.3 [Operating, in part] The scheme document is identified by its code and revision — EMET-S-01, revision as stated in its front matter — and the master text is held as a controlled file in the body's own source repository, where every change to it is recorded in the same append-only change history as the software it describes: who changed it, when, and the change itself. What is not operating: the scheme document does not appear in the body's forms register (Annex D.2), which covers only the five client-facing forms; EMET-S-01, the gap register, the impartiality risk register and the six EKS drafts are controlled by repository discipline alone, with no register recording their approval, current revision or distribution (ISO/IEC 17065, 8.3.2 c) and d)). Entering the body's own governing documents into a controlled register is a requirement of this scheme, recorded as a gap.

E.2 What triggers a revision

E.2.1 A revision of this scheme is initiated when any of the following occurs:

a) a change in a halachic ruling. The Rav HaMachshir's rulings are the substance behind every kashrut-substantive requirement; when a ruling changes — a condition's meaning, an ingredient policy, a Passover rule, the approval of an EKS document — the scheme text that states its process consequence is revised so that the document never describes a discipline the ruling has left behind. The ruling itself is never in this document (VI.0.3), so the revision records process, not halacha;

b) a change in the standards referenced. The body monitors the documents this scheme is drafted against — ISO/IEC 17065:2012, ISO/IEC 17067:2013 and Codex CXC 1-1969 — and its own normative documents, the EKS series; a new edition or amendment of any of them triggers a review of every clause traced to it (ISO/IEC 17067, 6.6.2). The cross-reference table in the front matter is the working tool: it is corrected in the same revision;

c) the outcome of a complaint or an appeal. Complaints and appeals are recorded as distinct case types, and an outcome that shows a rule of this scheme to be wrong, ambiguous or unworkable is an input to revision, not merely to the case (ISO/IEC 17067, 6.6.1 — feedback from stakeholders);

d) a nonconformity in the body's own operation. The gap register and the impartiality risk register record the body's open nonconformities; the closure of one, the discovery of one, and the escalation of one are each revision triggers, because a scheme that states a gap which has since closed — or fails to state one which has since opened — is false;

e) a change in what the software does. These annexes state system behaviour as built (VI.0.1), so a software change that alters any behaviour this document describes falsifies the text the moment it deploys. The rule mirrors D.1.2: the change to the system and the revision to the scheme belong to the same change. [Requirement] As with the forms register, nothing automated verifies this; it is a discipline on the change, and its observance is an item of the periodic review under E.6. The same principle — that a documented control is re-examined whenever the operation it governs changes — is the one this scheme imposes on its clients at the plant level (Codex CXC 1-1969, §13.1.5), and the body does not exempt itself from it.

E.2.2 There are no silent edits. A correction that changes no requirement — a typographical repair, a renumbering, a clarified sentence — is still made only by a new revision recorded in the revision history, because a published document that differs from itself under one revision number asserts that two different documents are the same document (D.1.2).

E.3 How a revision is made, reviewed and approved

E.3.1 [Requirement — not yet implemented as data; operated manually] A revision begins as a written proposal stating the change and the reason for it, and is classified before anything else as one of two kinds: halachic-substantive — it creates, alters or removes a requirement whose content is a matter of halacha, or changes the process by which a halachic determination is obtained or recorded in a way that could change its outcome — or administrative — everything else: process, drafting, numbering, description of system behaviour, correction of fact. Where the classification is doubtful, the change is treated as halachic-substantive and referred; the party proposing it is obliged to ask, exactly as clause 6.3 of the certification agreement obliges a holder unsure whether a change matters.

E.3.2 A halachic-substantive revision requires the decision of the Rav HaMachshir, and does not take effect without it. The discipline for recording that decision is the one the conditions module already operates as software for the certificate's condition wording (clause 19.11): the deciding signatory named; the date the decision was given; the channel by which it reached the office; and, where the operator recording it is not the rav himself, an explicit statement that it was recorded on his behalf. [Requirement — not yet implemented] For revisions of this scheme document, that record exists only in the revision history entry and the retained correspondence — the conditions module is the sole place the pattern runs as data. Extending the recorded-decision pattern to scheme revisions is a requirement of this scheme. What is recorded is that the Rav HaMachshir decided, when, and through what channel — never the halachic reasoning, which belongs to him and is not the scheme's to publish.

E.3.3 An administrative revision does not require the Rav HaMachshir. It is approved by the person responsible for the operation of the scheme, in writing, before issue (ISO/IEC 17065, 8.3.2 a) and b)). The boundary is absolute in one direction only: an administrative revision may never alter the substance of a halachic requirement, and if on review it is found to have done so, it is void to that extent and the prior text stands until a decision under E.3.2 is obtained.

E.3.4 Three governed texts have their own change procedures and are not revised through this clause: the certificate condition wording (clause 19.11, operating as an append-only recorded rabbinic decision); the certification agreement text (clause 19.10 — presently blocked by the re-acceptance gap, which is the highest-priority gap in Part IV); and the client-facing forms (D.1.2). A revision of this scheme document is required only where the scheme's description of those procedures changes.

E.3.5 Before approval, every revision is checked against the cross-reference table: the clauses of ISO/IEC 17065 and ISO/IEC 17067 the changed text traces to are re-verified, and the table, the gap register and the affected [Operating] / [Requirement] markers of these annexes are corrected in the same revision. A revision that changes a marker from [Requirement] to [Operating] must name the system behaviour that justifies it; the standing rule of VI.0.2 — nothing is described as operating that does not operate — binds the reviser above all.

E.4 How a revision reaches certificate holders

E.4.1 When a revision introduces new or revised requirements that affect holders, Emet notifies every affected holder in writing — what changed, what the holder must do, and by when — and verifies implementation (ISO/IEC 17065, 7.10.1; clause 19.10; certification agreement section 15). Each such revision states its own transition period (ISO/IEC 17067, 6.6.2), set when the revision is approved: for a halachic-substantive change, the transition — including whether any is permitted at all — is set as part of the Rav HaMachshir's decision under E.3.2, because how long an old rule may go on being relied upon is itself a question the scheme cannot answer for him.

E.4.2 The transition rule. A holder certified under a previous revision remains certified under the requirements in force at its most recent issue until the earlier of: the transition date the revision states, or the certification's next renewal — at which the current revision applies in full, enforced through the renewal gates of clause 20.6. A holder that cannot or will not implement a changed requirement by the stated date is reduced, suspended or terminated under section 21 (agreement clause 15.3). No holder is ever sanctioned against a requirement it was never told about: the notice under E.4.1 is a precondition of any consequence.

E.4.3 Not yet implemented, and inherited from clause 19.10: the system has no means of notifying all holders of a scheme change — outbound mail exists only per certificate, and no bulk or broadcast path exists — and no way to put a new agreement version to a holder who has already accepted an earlier one, so a revision that changes the agreement would today make every existing certification unrenewable with no route out. Until both paths exist, no revision affecting holders may be brought into force except with a transition period long enough for notification to be completed by hand, and no revision changing the agreement text may be made at all. Both are recorded as gaps; the second is blocking.

E.5 Publication and version control

E.5.1 The scheme requires that this document be published in full on the body's website; that the revision in force be the one so published; and that the document identify itself by code, revision number and effective date, with its complete revision history inside it, so that any reader holding any copy can answer the question which revision is this, and is it current from the front matter alone.

Not yet implemented: the public scheme page is a plain-language summary of the scheme's rules — granting, maintaining, extending, reducing, suspending, withdrawing, ending, refusing — and does not serve the text of EMET-S-01 at all. No revision number, document code or effective date appears anywhere on the page, so a reader of the site cannot determine which revision is in force, and the front matter's statement that the document is published in full at the site's scheme address is a statement of requirement ahead of implementation. This is recorded as a gap (ISO/IEC 17065, 8.3.2 d) — relevant versions available at points of use; ISO/IEC 17067, 6.7).

E.5.2 [Operating] Version control of the master text: the document lives in the body's source repository, its history is append-only, and every revision is recorded in the revision-history table in the front matter with its number, date and a statement of the change. A superseded revision is never destroyed; it remains identifiable in the repository history as superseded (ISO/IEC 17065, 8.3.2 g) — obsolete documents identified and their unintended use prevented). The revision number in the front matter is the sole authority for which text a copy is; a copy in circulation whose revision number does not match the published revision is superseded, and the published revision prevails — the same rule the register applies to certificates (clause 17.1), applied to the scheme itself.

E.6 Periodic review

E.6.1 The operation of the scheme is reviewed at least once in every twelve months (ISO/IEC 17067, 6.6.1; interval aligned with ISO/IEC 17065, 8.5.1.2), and the review examines at minimum:

a) truth of the text — that every behaviour these annexes describe as [Operating] still operates as described, tested against the running system, not against memory; b) the gap register — every open item re-affirmed, closed with the evidence named, or escalated; every [Requirement — not yet implemented] marker in this document re-verified; c) complaints and appeals — outcomes since the last review, and whether any exposed a defect in the scheme's rules rather than in a holder's conduct; d) the forgery signal — the verification-lookup analytics: never-issued lookups and the numbers most hunted (clause 17.10); e) the referenced documents — the editions of ISO/IEC 17065, ISO/IEC 17067 and Codex CXC 1-1969 in force, and the approval status of each EKS document; f) the impartiality risk register — each threat, its controls and its residual risk re-examined (clause 2.6); g) consistency of application — that the scheme's requirements are being applied in a consistent manner across holders and across the review period (ISO/IEC 17067, 6.6.1); h) the change disciplines — that D.1.2 (form revisions move with forms) and E.2.1 e) (scheme revisions move with software) were observed in every change made since the last review.

E.6.2 The output of the review is either a revision under E.3, or a recorded decision that none is needed — and the review itself is recorded: date, participants, inputs examined, conclusions. [Requirement — not yet implemented] No such review has yet been held, no procedure for it exists as anything but this clause, and no record of one exists anywhere in the system. The first review falls due no later than twelve months after this document's effective date. Where a review input touches a halachic requirement, the review may note it and refer it; it decides nothing halachic itself.

E.7 What is not yet in place to operate this annex

E.7.1 This clause states plainly, checked against the certification system as built, what the body does not yet have. Nothing here is softened, because this annex is the part of the scheme that keeps the rest of it honest, and it cannot do that while overstating itself.

a) There is no document-control system. The only document register in the software is the forms register — five client-facing forms, held in one place in code (Annex D.2). No procedure controls the body's internal and external documents generally; the scheme document, the EKS drafts, the gap register and the impartiality risk register are repository files with no recorded approval, distribution or obsolescence control (ISO/IEC 17065, 8.3 — none of 8.3.2 a) to g) is established as procedure).

b) There is no management review. No procedure, no record, no data model. The impartiality risk register names management review as its own review point, and that review point does not exist (ISO/IEC 17065, 8.5). Clause E.6 is the review this scheme requires; until it is held and recorded, it is a requirement on paper.

c) There is no internal audit. Nothing audits the body's own operation (ISO/IEC 17065, 8.6). The nearest artefact is the gap register itself — a clause-by-clause examination of the system against the scheme — which is a single written act, not a programme, and had no independence from the persons who built what it examined.

d) There is no corrective or preventive action process for the body. Findings, corrective actions, due dates and closure evidence exist in the system only against clients' facilities (clause 18.5). The body has no mechanism for recording, tracking or closing a nonconformity in its own operation (ISO/IEC 17065, 8.7, 8.8); the gap register lists, but nothing escalates, assigns or closes.

e) The scheme is not published in full, and carries no public revision indicator (E.5.1).

f) No holder-notification or agreement re-acceptance path exists (E.4.3), so no revision affecting holders can presently be executed through the system at all.

E.7.2 The consequence is stated without decoration: the body does not operate the management system of ISO/IEC 17065, clause 8, under either option, and claims no conformity to that clause or to any part of this document beyond what the [Operating] markers state. No assessment of this scheme against ISO/IEC 17065 or ISO/IEC 17067 has been performed by any party, and nothing in this annex asserts or implies otherwise (VI.0.4). Until the items above are closed, this annex operates by the manual means this Part records — revisions made and classified under E.3, decisions of the Rav HaMachshir recorded per E.3.2 in the revision history and retained correspondence, the review of E.6 held from a calendar kept outside the system — and every one of the gaps in E.7.1 is itself a standing input to that review.